Saving a useable STL file out of X7 Verify

[djstedman]

I am just making an educated guess here since I can't see a file, but in my experience Mastercam's verify has been hopelessly broken regarding retracts on rotary programs for a very long time.

 

In verify the verify engine processes the retract move as a move in Z+ relative to the tool axis normal to the surface of the part, rather than as a move in Z+ in the tool plane direction.

 

I am sure the problem stems from the fact that the verify of rotary programs does not simulate actual machine kinematics (ie. tool/table movement in XYZ axis's only with rotary movement in A) but rather displays the rotary as stationary with the tool moving in XYZ and rotating around the part rather than the part itself rotating relative to the tool axis.

 

Because of this behavior you get a retract along the tool axis normal to the part, on the machine however you get a retract in the Z+ direction that clears the part.  Then when the rotary rotates to the next position the tool moves from its current location (somewhere retracted from the part but not necessarily above it) to the next location - often this positional move to the next location will go 'through' the part in verify due to verify being a poor representation of how the machine actual moves in the real world.

 

This is why in simulation it works fine, because in simulation you are showing actual machine motion based on machine kinematics and in verify you are not.

[squirrel_41]

Well thanks very much for that I would say you have it in a nutshell.

I can get the part to verify using very touchy and precise entry and exit lead in outs .

But  if  you make a slight change to the tool depth or step over in any tool path it all goes out the back door.

In any case you are dead right about the location of the Z being relative to the tool plane and therefore the Z retract is a completely unknown.

These paths are transform rotate.

 

I also do not understand why there is no home location value for rotary axis.

In the tool linking if you enable start form home position and return to home position it goes  bad the XYZA can end up any where and this is also reflected in the G-Code and cost me many broken end mills and destroyed part.

 

So is it safe to say that if it verifies correctly in Machine simulation this is what I will get when I actually machine the part ?.

 

I am so glad that you have clarified this for me Its a pity this is not stated some where in the help files 

 

This has been a nightmare for me for many years ,it is only with the advent of machine simulation that I have been able to make some sense out of it.

I really thought I was going nuts because I have been chasing a answer to this for so long.

Because of this problem I have tried many other CAM  software and it is my personal opinion that with all it pitfalls Mastercam is still the best of the bunch if I was in business it would be my choice.

 

Thanks very much Guys 

I think I can finally put this to rest

Regards 

Bob Andrews.

[djstedman]

So far as retracts go, I often program these kind of paths using a 'force tool change' so that between paths the machine moves to toolchange position. The post I use is setup to always go home in Z first then XY, so by forcing a tool change I know the tool will always be out of the way prior to making any weird rotational moves. 

 

 

So far as machine simulation goes, I wouldn't say you could take for granted that it will always be correct either.

 

For this one particular issue it most likely will be correct, but you have to keep in mind that it doesn't matter if you are using verify or machine simulation, what you are seeing is what is coming from Mastercam BEFORE it goes through the post processor.  So depending on how your post interprets the NCI file your G-code can do something else entirely.

 

A better method for verifying code is to use a verification software that displays actual g-code that is run through a simulation of the specific machine you intend to run the g-code on, such as Vericut.

 

And even that can have errors if the machine is not setup to perfectly mimic the machine itself.

 

So far as I am concerned the only truly proven code is code that has actually run on the machine, because of this first run programs are still always stepped through carefully to prove them out before they can be run full speed.

[squirrel_41]

Machine Simulation Transform rotate would not work so I tried this and it worked perfectly

 

 

 

Mastercam X7 what I did was transform rotate

Then save the NCI

then Import the NCI

Then simulate the imported NCI it works  correctly

If anybody wants a copy of this file I will email it to you.