What's new
What's new

How do YOU avoid collisions and crashes?

thats great in 3 axis work. how you gonna do that in 5 axis? especially simultaneous...
You'd rather wreck your 5 axis?
The few times I had to prove one out, I would creep up with rapids way down, and single block the first few lines.
I'd concentrate on tool change lines and such where the possibility of a bad command is greater.
With that, I don't have a 5ax in my shop and unlikely in the near future, so I prove out as stated before.
So far, so good.
 
I guess it depends on the volume of work you do. Last year we did close to 90,000 unique details on our CNC machines. Not trusting our simulation software would be costly.
Properly set, you may have more faith in it than I do, and I can see why you would do so.
I just never felt at ease with it.
 
You'd rather wreck your 5 axis?
The few times I had to prove one out, I would creep up with rapids way down, and single block the first few lines.
I'd concentrate on tool change lines and such where the possibility of a bad command is greater.
With that, I don't have a 5ax in my shop and unlikely in the near future, so I prove out as stated before.
So far, so good.
no, i'd rather prove the post thoroughly, make sure it doesnt do anything i dont expect with a few different programs/parts - then rely on the software. if i sat through a 10mb program with single block on or even reduced rapids/feeds - i'd never get anything done.
what you're doing is fine for simple 3 axis work, although i use the same principle here. once i've proven out my post and set up my rapid height defaults - there is no reason to hand hold every new program if your verification comes back good. i'd only do what you're describing on super expensive one off parts.
 
Several ways depending on weather I am proving out a new problem or running in MDI. New program: single step thru and looking at the next line before exituting.
Or moving away from the work piece and running
 
In my experience if you have a proven post it's pretty rare you will encounter an issue, and if you do it's more than likely a human error.

But from what I've experienced typically any issues I've had is after a post edit and the issues tend to be in between individual operations within the same tool, it may not recognize a rapid plane height and use a feed clearance plane or something of that nature. I've yet to see an actual operations tool path have issues, so for me say a surfacing program, if I step through and hit my rapid and feed clearance heights right and hits that G01, I trust it.

For me that's where I verify in a back plotter, when I post my program it auto opens in my editor and the back plotter is auto generates and I can quickly verify the yellow lines that are rapids and notice if there is anything funny going on.
 
Properly set, you may have more faith in it than I do, and I can see why you would do so.
I just never felt at ease with it.
It is critically important that the support for any verification software is top notch. As mentioned earlier we use Eureka with the Lemoine Technologies app. We've had features added just for us to make it even safer. For example, we may check a toolpath on Monday, but doesn't go into the cell until Wednesday. Because we have Eureka reading the controller's tool table we know exactly whether the tools in the ATC are the same as when we verified the toolpath. Without the phenomenal support we receive through Lemoine we wouldn't have this. So if someone changed a tool length offset between the Monday and Wednesday we could have a crash. So my recommendation for anyone contemplating adding verification software is to research the support just as much as the solution.
 
has a licensed proprietary additional cost add in licensed product from a third party provider
FWIW,
The ModuleWorks simulation that is in Mastercam is not a paid option add-in. It comes with the seat of Mastercam. It's no additional cost to the purchaser.
 
Memory tells me it all went.to court and CNC Software (Mastercam) won their case that their trochoidal algorithm was "originally different"....
Off topic but oh well. This thread became tired anyway, lol.
I heard about MC too, as well as Surfcam possibly having some patents covering it. Siemens seemed to be dragging their feet in getting their adaptive to market for sure. I asked one of their gurus what was going on and that's when he divulged the legal fights, off the record, and said they were waiting to hear the court decision. I can only imagine the huge license fees the real patent holder is receiving; we'll probably never know for sure, lol.
 
I'll sometimes single block until the tool is in the cut, more often just 25% rapid while hovering over the feed hold and keeping an eye on distance to go. Can't slow down and "prove out" every program when doing prototypes and short runs or I'd never make any money.

Once the tool is in the cut, let'er rip. No way am I single blocking 10,000 lines of dynamic roughing. That would take all week to get through a half-hour program.
 
Last edited:
i know. still Gcode simulation. it simulates what it posts.

Wrong. It absolutely does not.


I asked camplete support how I can suppress G53 Z0 retract moves and use TCP linking moves for a bunch of deburring toolpaths. They happily obliged and modified my post. Resulting simulations showed exactly how I pictured it. Tool tip follows the part around as it rotates. Great, except the g-code it generated was totally wrong. It didn't even have TCP enabled... Code was standard indexing moves, just no G53 Z0. Yet their simulation shows the tool following the part around as it rotates. Machine did exactly what I thought it might do. Tool doesn't retract, just sitting there, A/C rotate, then next tilted plane, XY, and G43Z. Would've made a spectacular crash.
 
NX simulates with a copy of the post used for outputting gcode. It can also simply simulate using the operations, which is what I do for simple 3-axis parts. A friend's company uses Creo to make rocket engine components; I'll ask him how Creo does it when I get a chance.
We at KU Leuven (Belgium) use VERICUT software from CGTECH. We use Creo 6.0 for 5-axis toolpath creation and postprocessing from CL file to EIA/ISO file. We delivered the 3D assembly of our MAZAK 5-axis CNC to CGTECH and they created the virtual CNC machine in their Vericut software. We put the EIA/ISO programs in vericut as if we put them in the real machine. When it works cllisiin free in Vericut , it also goes fine on the machine if we make exactly the same setup. We use Vericut as separated software. So we can put files from other CAM software in it to simulate for our MAZAK CNC.
 
We at KU Leuven (Belgium) use VERICUT software from CGTECH. We use Creo 6.0 for 5-axis toolpath creation and postprocessing from CL file to EIA/ISO file. We delivered the 3D assembly of our MAZAK 5-axis CNC to CGTECH and they created the virtual CNC machine in their Vericut software. We put the EIA/ISO programs in vericut as if we put them in the real machine. When it works cllisiin free in Vericut , it also goes fine on the machine if we make exactly the same setup. We use Vericut as separated software. So we can put files from other CAM software in it to simulate for our MAZAK CNC.
Vericut does a very nice job for sure. Do you know if Creo has the ability to verify posted code?
 
i know. still Gcode simulation. it simulates what it posts.
If you want true G code simulation, you need a 3rd party software to do it. (Vericut) among a select few others. Using CAMPlete and saying it simulates it's G code, is no different than me saying Powermill creates and simulates it's G code. Ask CAMPlete to IMPORT a G code file and simulate it, listen carefully to their response.
 
If you want true G code simulation, you need a 3rd party software to do it. (Vericut) among a select few others. Using CAMPlete and saying it simulates it's G code, is no different than me saying Powermill creates and simulates it's G code. Ask CAMPlete to IMPORT a G code file and simulate it, listen carefully to their response.
by that logic, NX cant simulate Gcode either because you cant import an external file to sim it?
 
by that logic, NX cant simulate Gcode either because you cant import an external file to sim it?
What is the point in collision checking a G code simulated by the same software as the one that created it? A third party crash protection is your safest bet. Trust me, I have been down this road with a file that took out a spindle years ago, Vericut was the only one who caught it. And before you ask, no I don't work for them.
 
What is the point in collision checking a G code simulated by the same software as the one that created it? A third party crash protection is your safest bet. Trust me, I have been down this road with a file that took out a spindle years ago, Vericut was the only one who caught it. And before you ask, no I don't work for them.
what does it matter, as long as its the actual Gcode being simulated, not the NCI file?
the issue is the extra translation step from NCI to NC file. as long as you eliminate that step, and simulate the NC code, you're good.
 








 
Back
Top