What's new
What's new

How do YOU avoid collisions and crashes?

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...
Yeah...I've got my fair share of gripes with Mastercam, but that post based verification isn't one of them. It's been bulletproof for me.
 
Actually kind of surprised empower didn't bring it up himself, but NX has built in G-code simulation.


Sure wish my job had it set up. :(
 
camplete is a GREAT option for true G code simulator. it aint cheap, but they set everything up for you.
That's not quite accurate. Camplete is not a G-code simulator. It definitely does not simulate G-code like a real machine control does.

Out of the box with standard settings, sure it works just fine for 99% of users and it should accurately depict what the machine will do. But it certainly does not simulate actual G-code. This is false.

How do I know? Well, 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.
 
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...
cool story
 
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'.
how do you explain machsim (using external post as you're saying) showing no collisions during a linking move, but in real life that same exact move with NO changes runs the cutter through the part?
 
how do you explain machsim (using external post as you're saying) showing no collisions during a linking move, but in real life that same exact move with NO changes runs the cutter through the part?
There is a tab somewhere in the masterscam setup which allows automatic rapids through the part. You just need to uncheck this box.
 
how do you explain machsim (using external post as you're saying) showing no collisions during a linking move, but in real life that same exact move with NO changes runs the cutter through the part?
You expect me to troubleshoot your crash off of just that sentence:nutter:
How about you start with what machine/post/toolpath. Maybe upload a file.
 
Vericut is an answer, but it's not the only answer. We use Eureka from Roboris:


Lemoine Technolgies has created an application that makes Eureka very painless to use. You can simulate your actual G-code within minutes. Because Eureka has an API you can take it as far as you want to. We have it down to a couple of mouse clicks, and for one of our cells, it's completely automated. In other words, toolpaths are checked with no human intervention. The cost is about 1/3 of Vericut from what I recall (I know the price of Eureka, but going from memory on a Vericut quote from a few years ago). Nothing runs on our cells that hasn't been verified with Eureka. And after about 6 years of using it, it has not let us down once. If it says the toolpath is safe, then it's safe.
 
You expect me to troubleshoot your crash off of just that sentence:nutter:
How about you start with what machine/post/toolpath. Maybe upload a file.
not sure the board will accept a 1+gb file
postability umc750 post/sim setup. neither mastercam nor postability had an answer, lol.
 
not sure the board will accept a 1+gb file
postability umc750 post/sim setup. neither mastercam nor postability had an answer, lol.
I can't help either without seeing a file and then running the code.
Screen record the sim, screen grab the section of code.
 
I can't help either without seeing a file and then running the code.
Screen record the sim, screen grab the section of code.
past the point of helping, reprogrammed it to a different style toolpath and its fine now. i'm not saying im an expert - far from it. but i've been around the block awhile, and when i talked to mastercam and postability, i supplied them the program, code, pictures of what happened and where. they had no answer for me. the list of fucked up shit mastercant has done is ginormous. sure i've made mistakes as well, but there were PLENTY times where tech support looked at me like deer in headlights. and i KNOW i'm not the only one that constantly has issues with it.
 
I use my simulator in CAMWorks, I try to program and use actual holders and out of holder lengths to get it as accurate as I can and use holder and shank avoidance options when needed.

I know the simulation doesn't run off actual g code, but the very few times my g code has ever differed from my simulation, maybe 3-5 times over 15 years, it was right after a post edit.

When I post my program in CAMWorks, it automatically opens my NC file in Cimco Edit and I have a third monitor that always has Cimco with the back plotter open and updates the file instantly, I always take a quick glance at it to see if there is anything obviously wrong, usually the difference was always a stray rapid or line movement that went off somewhere random and was easily seen.

There is definitely better options out there as stated above, but this works for me.

One thing I dislike about HAAS is not having a 0% Rapid option, I always liked to leave it set at 0% when stepping through a new program and could let an operation run and used the 0% as a pause in between operations that use the same tool. The dog leg rapids have kicked my ass a couple times too!
 
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.

A common crash not shown is dog leg rapids. Rapid move makes dog leg on machine where it shows a straight point to point in the sim.
 
I think even masterscam has a setting for high feed rapids.
Programming a G0 when you're below your clearance plane is a good way to get fired.
I've since adjusted my default rapid height to always be above stock. Where it always got me was if there were holes (drilled, reamed or tapped) on a lower surface plane and looking at the movement it never hit any higher surfaces or on plate work and hit a clamp.
 
You really do need to verify everything you do. Period. For 3 axis parts all you really need is operation based part sim. However, for 4 or 5 axis you really need to verify everything; simple operation based sim is ok but full blown, post processed file sim using accurate machine and fixture models is a must.

If you are committed to your cam software and its verification is not very good then I recommend Vericut.

If you are ever thinking of switching...some systems, such as NX, offer the capability to create your own machine sims, albeit with a fair amount of reading docs and watching videos. NX can verify postprocessed code from the internal operations, internal operations directly and external nc code. The first method is the most reliable and ahead of verifying internal operations. The last method really is only for verifying legacy nc files for which you have no cad cam file, for verifying a 3rd party nc file or for verifying an nc file from a colleague who runs inferior cad cam software and they have asked you for help to trouble shoot their bad program that just piled up a part, the tooling and an expensive fixture. ;)
 








 
Back
Top