How do YOU avoid collisions and crashes?

[huleo]

Running Mastercam but this question could be open to all. We are going to be bringing in 5x machining and that will bring new challenges in programming. As of right now, we do not model up the machines in MC for collision conflict info. That may need to change, though. Watching a 5x parts run, it appears running the spindle nose into the part itself could be the biggest challenge.

I am just curious what techniques you guys have found helpful to avoid conflicts? This could extend even to 4th axis HMC pallet rotation as well.

 

[Larry Dickman]

Vericut. It's expensive, but so is crashing a new 5x machine

 

[huleo]

Yup, I know several shops running it. You completely model your equipment and drop the posted program in? I want to say I used it many years ago but found it WAY overkill for 3 axis stuff and was faster to just turn a machine down to snail and do a dry run.

 

[mhajicek]

Vericut is the correct answer.

 

[riverside_eng]

Yup, I know several shops running it. You completely model your equipment and drop the posted program in? I want to say I used it many years ago but found it WAY overkill for 3 axis stuff and was faster to just turn a machine down to snail and do a dry run.

Simulating with the G code (inside Mastercam or with an external solution) is really the best way to address the risk.

It does require decently accurate models of:

Tools and Holders
Fixtures
Machine

 

[plastikdreams]

Just something to chew on...my advanced g code teacher once told us there are 2 types of machinists, those that have crashed a machine and those that are fucking liars.

 

[dodgin]

Vericut is the right answer.

But for those of us that don't have that luxury, Mastercam actually has machine simulations that work (for the most part) really well. I routinely use it to make sure I'm not going to crash into anything and it's been really handy when you're doing a job that is beyond the scope of the work envelope of the machine.

Only thing is I'm really neurotic. Every tool has a holder, and every holder has been measured and drawn up by me. Every fixture/vise/setup is modeled in, complete with bolts or washers or whatever else is going in with it.

Despite not proving out the actual code, it's never failed me. I'd say as long as you have a programmer that's buttoned up nicely it should do the trick.

 

[empower]

Running Mastercam but this question could be open to all. We are going to be bringing in 5x machining and that will bring new challenges in programming. As of right now, we do not model up the machines in MC for collision conflict info. That may need to change, though. Watching a 5x parts run, it appears running the spindle nose into the part itself could be the biggest challenge.

I am just curious what techniques you guys have found helpful to avoid conflicts? This could extend even to 4th axis HMC pallet rotation as well.

before you get into anything like vericut, camplete, or other methods of simulation = #1 thing is SLOW THE FUCK DOWN, double and triple check that what you have in CAM corresponds to what's on the machine. no simulation will help if you're using holders that are different from what you have in CAM, or gauge/tool lengths are wrong.
i dont trust mastercrap simulation worth a fuck. just recently ran a part that both verify and machine sim showed perfect, go to run the part, and the tool plows into it. i'll keep saying it, MC = worst piece of software in general i've ever seen.
vericut and camplete are legit.

 

[empower]

Simulating with the G code (inside Mastercam or with an external solution) is really the best way to address the risk.

It does require decently accurate models of:

Tools and Holders
Fixtures
Machine

mastercant does NOT simulate G code

 

[riverside_eng]

mastercant does NOT simulate G code

Sorry, guess I should have said the Moduleworks simulation packaged with Mastercam. Driven by a CL file created from the G code file.

 

[empower]

Sorry, guess I should have said the Moduleworks simulation packaged with Mastercam. Driven by a CL file created from the G code file.

still, no. its not G code simulation. it simulates from the CL file. i've personally had mastercant machine sim show a program to be perfectly fine, then the program ran a tool straight through the part during a reposition/5axis linking move. true Gcode sim would catch that.

 

[riverside_eng]

still, no. its not G code simulation. it simulates from the CL file. i've personally had mastercant machine sim show a program to be perfectly fine, then the program ran a tool straight through the part during a reposition/5axis linking move. true Gcode sim would catch that.

Yes, that seems like the machine sim where the CL was based on the NCI level data not g code. So more parallel to g code than working off of it.

I am talking about something new. G code based. It uses similar emulator software to what has been available in CATIA/3dExperience for years for NC code simulation.

<I work for the emulator company>

You are right, toolpath based simulation doesn't hold a candle to g code based.

 

[huleo]

Seems like Vericut is the most voted here for a true Gcode simulator. A true pain to program every single feature of a machine in, but I might have to look harder. I did find that one company uses it as their post processor. However, I am one to edit posts and theirs is apparently locked down. I would not accept that.

I think as far as mastercam goes, I found their lathe stuff to be horrid, but I have a policy of wanting everything generated out of CAM.

I will usually consider about any approach to minimize crash hazards. I usually irritate people when I want a program run dry, at reduced rapids, and finger on the feed hold the entire time. Only issue I have had so far is forgetting about a tool clamp and breaking a tool off. Nothing yet that has caused machine damage, and I'd like to keep it that way. But I do know some parts that run for many hours and it is just not practical to dry run sometimes.

I have 'caught' potential crashes by pausing the program, looking at distance to go, values in the program, etc. Sometimes I fat finger the programming.

 

[empower]

Seems like Vericut is the most voted here for a true Gcode simulator. A true pain to program every single feature of a machine in, but I might have to look harder. I did find that one company uses it as their post processor. However, I am one to edit posts and theirs is apparently locked down. I would not accept that.

I think as far as mastercam goes, I found their lathe stuff to be horrid, but I have a policy of wanting everything generated out of CAM.

I will usually consider about any approach to minimize crash hazards. I usually irritate people when I want a program run dry, at reduced rapids, and finger on the feed hold the entire time. Only issue I have had so far is forgetting about a tool clamp and breaking a tool off. Nothing yet that has caused machine damage, and I'd like to keep it that way. But I do know some parts that run for many hours and it is just not practical to dry run sometimes.

I have 'caught' potential crashes by pausing the program, looking at distance to go, values in the program, etc. Sometimes I fat finger the programming.

camplete is a GREAT option for true G code simulator. it aint cheap, but they set everything up for you.

 

[empower]

Yes, that seems like the machine sim where the CL was based on the NCI level data not g code. So more parallel to g code than working off of it.

I am talking about something new. G code based. It uses similar emulator software to what has been available in CATIA/3dExperience for years for NC code simulation.

<I work for the emulator company>

You are right, toolpath based simulation doesn't hold a candle to g code based.

so what is this 'something new'?

 

[goooose]

still, no. its not G code simulation. it simulates from the CL file.

And Vericut run on a computer does not contain the same hardware as a CNC control. It is still translating gcode into how it thinks the machine will move. This is the same thing Mastercam MachSim is doing. CL vs gcode, doesn't matter. The CL code is turned into gcode, the machine runs the gcode. The post writer for Mastercam can control MachSim based on how they are outputting the gcode. They don't need to turn the CL code into gcode, and then re-read it to drive the sim.

I won't say the Mastercam MachSim that is post driven is the same as Vericut because Vericut does much much more, but as far as seeing accurate machine movement, you're good either way.

 

[empower]

And Vericut run on a computer does not contain the same hardware as a CNC control. It is still translating gcode into how it thinks the machine will move. This is the same thing Mastercam MachSim is doing. CL vs gcode, doesn't matter. The CL code is turned into gcode, the machine runs the gcode. The post writer for Mastercam can control MachSim based on how they are outputting the gcode. They don't need to turn the CL code into gcode, and then re-read it to drive the sim.

I won't say the Mastercam MachSim that is post driven is the same as Vericut because Vericut does much much more, but as far as seeing accurate machine movement, you're good either way.

you're utterly wrong. it does matter because if you're simulating CL, and its good, then your post processor converts that to Gcode, you're introducing a variable that can easily change the outputted code.
if machines were reading CL code, completely different story.
the main factor here is that there's an extra step in translation between CL simulation and posted code, which is where a LOT of dangerous errors can be introduced.

 

[goooose]

you're utterly wrong. it does matter because if you're simulating CL, and its good, then your post processor converts that to Gcode, you're introducing a variable that can easily change the outputted code.
if machines were reading CL code, completely different story.
the main factor here is that there's an extra step in translation between CL simulation and posted code, which is where a LOT of dangerous errors can be introduced.

I don't think you understand the effect of a linked post to MachSim in Mastercam. This is different than generic MachSim.

If you are NOT using a linked post, yes, you could get some differences between sim and machine. If the post is driving MachSim, the information in the post that creates the gcode is the same logic used to drive MachSim, both created by the post dev. The translation from graphical toolpath to machine motion and to gcode is happening in the same place, the post.

Nothing wrong with softwares like Vericut/NCSimul. They are awesome and do much more than just sim toolpaths, and their price tags reflect that awesomeness. Just don't think that's the only way to get accurate machine simulation because they 'use gcode'.

 

[huleo]

I often wonder what is really causing crashes. Is it 'really' a posted code issue or is it more likely to be a programmer issue? I think for me, most problems can be found when backplotting the paths, but I guess secondary or aux functions could throw odd wrenches.

it just seems like I see issues where machines do odd things, and I often wonder why there are not controlled tests done with the machine to confirm the posted Gcode is correct.

I know one post I love uses internal subroutines and we have the post modded to put a certain Z retract on for each offset. That is something you CAN'T see until posted. I think most of the odd behaviors I have seen were on lathes. There are always little things like running the turret in so you can bump stock to it or something. That is hard stuff to CAM program.

 

[Mike1974]

well, just mention mastercam and empower will be all up your ass on how bad it is. used it for going on 18 years, not crashed very many parts due to mastercam, vs me being a dumbass. empower don't know how to use it PERIOD. no way, no how; someone with that experience having these issues with a very very easy cam software. portability use to sell 5 axis sim and post for the UMC 750 that was very good 5k, and never crashed using it...