Hitting the wall in XP

[Brakeman Bob]

Just something I thought I'd share with you all. I have been programming a new job over the last few weeks that has a lot of curvy surfaces and when running the job through in SolidVerify I get so far and then "BAM", SolidVerify crashes. It has really got on my nerves especially as I had to send code to the machine "unverified" and some of the five axis stuff was, er, energetic to say the least.

Getting touch with SolidCAM and FTP'ing my part file (all 255 Mb of it) the response came back that it was lack of memory and sure enough when I ran SolidVerify with TaskManager active I saw SolidCAM taking over 1½ Gb of memory. Thinks were ok as long as I didn't try to move, rotate or zoom in on the part - as soon as I did that the display froze and got that dialog box "SolidCAM has encountered a problem and needs to close....."

I did manage to run MachSim but not in Verify mode, but isn't the same as SolidVerify. No lurid colours for different tools (I'm very fond of shocking pink and turquoise for my ballnose endmills), no zooming in to see a patch of uncut material where I needed to tweak a boundary, no warning that the tool was about to plunge into a lump of stock that I'd thought I'd taken off 50 jobs back up the job tree. No, just not the same.

So as soon as I have finished this beast of a part I shall be upgrading to Windows 7 where, I am told everything will be wonderful (but my printer won't work).

To give some indication of part complexity, an stl of the part clocked in at over 25 million triangles (that being the taget model in SolidVerify at a facet tolerance of 0.1mm) and I used 34 MAC positions and 210 jobs in the OP1 alone. Is there anyone else pushing SolidCAM (or should I say Windows XP) to these limits? I'd love to talk about how you cope with such unwieldy buggers because I am running out of ideas (and I still have the OP2 and the opposite hand of the part to program).

Cheers.

[mattpatt]

That sure is a mighty part you're working with there.

The mold I just made was a mere 30mb, and an upcoming job is a shade bigger at 36mb.

One shortfall is my ancient computer (XP), so that halfway through the solid verify I do have to put a few more turns in the rubber band to stop it grinding to a halt :-)

Playing on my friend computer the other day with solidworks (doesn't have solidcam) it was way faster than mine during rebuilding the model etc. So much so that I considered waiting for him to go out and then running away with it ;-)

I think I too need an upgrade. Better start saving the pennies.

Matt.

[Brakeman Bob]

I am planning to move over to Windows 7 when I have finished working out what the implications might be for other software I use.

My PC is 2 years old but is still fast by todays standards. Windows XP's memory throttle really cripples graphics intensive applications such as SolidVerify. For the record, is my current setup

CPU: Intel Core 2 Duo E6850
Motherboard: DP43TF
4 Gb DDR2 800MHz RAM
Graphics card: Nvidia Quadro FX4600 driver 191.66

Windows XP Professional SP3
SolidCAM 2009 SP3
SolidWorks 2009 SP 4.1

I shall report on my experiences with Windows 7

[ger21]

In order to be able to use more memory, don't you need to use 64bit Windows 7 with 64 bit versions of Solidworks and SolidCAM?

If you use the same software, won't you still have the same memory limitations, which are dictated by the 32bit software?

[Brakeman Bob]

Originally Posted by ger21 In order to be able to use more memory, don't you need to use 64bit Windows 7 with 64 bit versions of Solidworks and SolidCAM? If you use the same software, won't you still have the same memory limitations, which are dictated by the 32bit software?

Yes, I will be moving over to Windows 7 64 bit, SolidWorks 2009 64 bit and sticking with SolidCAM 2009. SolidCAM assure me that such a set up will be able to access the memory closed to Windows XP. I know that SolidWorks say that their software will not support Windows 7 until SW2010 SP1 but scouring the user forums SW 2009 doesn't havfe a problem with Windows 7 unless you want to use the Vault (thankfully we don't here).

I have been quoted 350 GBP to have my workstation upgraded to Windows 7 64 bit Pro and upping my RAM to 8 Gb. This is peanuts compared to how much a spindle crash would cost the company in terms of lost production. Just got to get somebody to sign it off.....

[dengo]

Originally Posted by Brakeman Bob To give some indication of part complexity, an stl of the part clocked in at over 25 million triangles (that being the taget model in SolidVerify at a facet tolerance of 0.1mm) and I used 34 MAC positions and 210 jobs in the OP1 alone. Is there anyone else pushing SolidCAM (or should I say Windows XP) to these limits? I'd love to talk about how you cope with such unwieldy buggers because I am running out of ideas (and I still have the OP2 and the opposite hand of the part to program). Cheers.

I did a part before Christmas in 4 Axis that weighed in at 75mb.
Doesn't sound much but the stock size was 40mm x 30mm x 50mm tall.
The Gcode txt file alone came out just shy of 3MB.

[jake_tb]

This problem you talk about with solid verify is something I hit with almost all my parts as the are very large in physical size (quite a few keels for boats so around 3-5 meters long). My last part totaled 829mb. I also don't like posting code unless I have simulated it in solid so the only way I can do it is decrease the accuracy to between 0.5 - 1.0 depending on job size. I have also found a slow way around witch is the use the manual stock update method. To use this you need to turn off the auto update (little rocket ship symbol in the solid verify screen) and save each operation as FCT or STL then open the saved file to run the next operation. This works but is very slow! I think you can also turn off the automatic stock update in the Cam setting page under simulation. Using this method I have not yet hit a limit on file size the simulator wont handle!

Jake

[Brakeman Bob]

I haven't had Auto-Update on for years and invariablyI have the "update stock model" set to manual and save the STF (or is it FCT?) file after every toolchange. Even then, after some particularly curvy geometry is cut either by 3D or 5X SolidVerify can't save the file or if it does save, can't load it back in.

The wall I hit in XP is still there in Windows 7, though it has moved a little. The part I could not even complete in SolidVerify now gets to the end but if after the SolidCAM process (viewed in TaskManager) gets to about 1 Gb any attempt to rotate the part or zoom in / out results in SolidCAM crashing. Mind you, it does it very elegently in Windows 7 so perhaps I should be grateful for that. I spent last Thursday working through settings on the advice of SolidCAM Europe Support trying to determine if it was a graphics driver problem or not and the outcome was that the problem definately lies in SolidCAM or in the modules bought off MachineWorks. The problem has been referred back to the developers in Israel and now we wait to find out if a patch form SolidCAM can fix it or does it need MachineWorks to change the behaviour of their code. If it's latter then we might be waiting some time.....

[thebowman]

Originally Posted by Brakeman Bob I haven't had Auto-Update on for years and invariablyI have the "update stock model" set to manual and save the STF (or is it FCT?) file after every toolchange. Even then, after some particularly curvy geometry is cut either by 3D or 5X SolidVerify can't save the file or if it does save, can't load it back in. The wall I hit in XP is still there in Windows 7, though it has moved a little. The part I could not even complete in SolidVerify now gets to the end but if after the SolidCAM process (viewed in TaskManager) gets to about 1 Gb any attempt to rotate the part or zoom in / out results in SolidCAM crashing. Mind you, it does it very elegently in Windows 7 so perhaps I should be grateful for that. I spent last Thursday working through settings on the advice of SolidCAM Europe Support trying to determine if it was a graphics driver problem or not and the outcome was that the problem definately lies in SolidCAM or in the modules bought off MachineWorks. The problem has been referred back to the developers in Israel and now we wait to find out if a patch form SolidCAM can fix it or does it need MachineWorks to change the behaviour of their code. If it's latter then we might be waiting some time.....

It's time to move away from MachineWorks and go with a robust simulation package that can handle an advanced user like you. The robust simulation package I'm thinking of is expensive but the support is the best in the industry and the program is absolutely phenomenal... CG Tech Vericut. When you use Vericut what you see is really what you get because it's verifies the actual G-code rather than some internal CAM file like MachineWorks does.

[kling8]

I have had that problem too. what I have done is get creative with programing the part, if there is different ways to machine. On some programs I have broken the 1 program into several programs, it sucks not the way I would like to make it, but what ever it takes to get the job done.

[Brakeman Bob]

Originally Posted by thebowman It's time to move away from MachineWorks and go with a robust simulation package that can handle an advanced user like you. The robust simulation package I'm thinking of is expensive but the support is the best in the industry and the program is absolutely phenomenal... CG Tech Vericut. When you use Vericut what you see is really what you get because it's verifies the actual G-code rather than some internal CAM file like MachineWorks does.

This is interesting. In 2007 I was told CG Tech were using the MachineWorks graphics engine in Vericut. So have they developed their own or are using ModuleWorks?

I have used Vericut in another life and have a lot of respect for the product but I did find disruptive to my workflow - having to post out code and push it through another application - though it did occur to me that you could have the CAM running on one PC and Vericut on another. Then you be working on the CAM whilst Vericut is chuntering through the simulation until you get to the bit you really want to see.

Another simulation package that is worth looking at is NC Simul - not anything like the market share of Vericut and hence not so well known, but a very competent package (or at least it was when i was evaluating it). And then of course there is the offering from Predator. We looked at this in 2006 but back then Predator had a problem with Heidenhains "PLANE SPATIAL" commands, using instead the old CYCLE 19 format. We didn't want to go backwards, especially as I still think a move over to TCPM and tool vector programming could offer benefits.

Yes, Vericut is an option, but at 25k GBP in this current climate I think it is one that will remain "nice to have".

Bob

[thebowman]

"This is interesting. In 2007 I was told CG Tech were using the MachineWorks graphics engine in Vericut. So have they developed their own or are using ModuleWorks?"


Simply no truth to this at all. In fact, Vericut was on the market long before LightWorks even developed MachineWorks.


"I have used Vericut in another life and have a lot of respect for the product but I did find disruptive to my workflow - having to post out code and push it through another application - though it did occur to me that you could have the CAM running on one PC and Vericut on another. Then you be working on the CAM whilst Vericut is chuntering through the simulation until you get to the bit you really want to see."

You're correct. Vericut is not as integrated as the MachineWorks component is.


"Another simulation package that is worth looking at is NC Simul - not anything like the market share of Vericut and hence not so well known, but a very competent package (or at least it was when i was evaluating it)."

There are others as well.


"Yes, Vericut is an option, but at 25k GBP in this current climate I think it is one that will remain "nice to have"."

The best and great support don't come cheap.

The best integration of MachineWorks in a CAM product is without a doubt DP Technology Esprit. A few years ago DP Technology purchased a company called Binary Spaces. I suspect that even with the best integration of MachineWorks that DP Technology knew they needed something better.