Linear Moves Galore! How to STOP!

[Kampfzentrum]

So one of my operators comes complaining to me, he's upset because Mastercam posts so many redundant paths in the same axis. For instance, if travelling in X Mastercam will program a lead in (in the case that the lead in is on line with the path, no arc/perpendicular lead in), the tool path, then lead out. What this does is leaves multiple blocks all in the same direction when really Mastercam could just be intuitive and delete the additional unnecessary blocks. In case I'm not being clear:

 

G01 X5.000

X10.000

X15.000

G00 Z4.000

 

This would also help out with other machines where I have to enable the "look ahead" feature or they stutter on each one of those positions.

The same goes for arcs, any advice?

 

[lowcountrycamo]

Is your chain made of several line segments?  Is he using "Adjust start length" on the lead in out page?

[Goldorak]

parallel lead in/out and extensions are always post like that 

to avoid this, draw a full entity and chain it without lead in/out 

 

the posted code should be cleaner 

[nickbe10]

1 hour ago, Kampfzentrum said:

The same goes for arcs, any advice?

This is because Mastercam uses discreet geometry (entities). Any lead in lead out is also considered an entity, so a code segment is posted for each.

The only CAM systems I know of which won't naturally do this is APT (for instance NCL ) which uses unbounded geometry.

There might be some GUI systems which have the ability to filter this out during  post processing but I am not aware of them.

This used to be a problem when memory was at a premium (APT systems generally generate about 20% - 30% less code than a typical GUI), but these days memory is so cheap and machines come with plenty, so it is really a non issue. Just look at how much code a typical High Feed Toolpath spits out.

The jerky motion you refer to is caused by driving splines with toolpath. These can usually be overcome by:

1) Convert spline geometry to arcs before using it in toolpaths (Edit/Simplify)

2) On geometry which can't be simplified use arc/line filtering in the toolpath

Usually only very complex surfaces with fine pitch splines require machine "look ahead".

[Watcher]

This is a not a Mastercam problem but rather a design approach used by several CAM systems. 

And for a number of reasons it is the best approach for the problem although operators may not like it. 

CAM was not invented with operators in mind, but rather to obtain reliable and predictable results and times during the development of a process to cut a part. 

[Grimes]

Back in the day I used to care about having efficient programs when manually programming, these days I dont as long as it gets the job done. Had a talk to our shop manager about it, he still uses mastercam 9 if you can believe it, that was his problem with mastercam. Ive got a mill that cannot move all three axis at the same time, every time I thread mill or helix on it using linearize the helix the program is HUGE, but it gets the job done so im fine with it.

[Colin Gilchrist]

The issue is that the Post Processor doesn't know anything about your path. It only knows "what the current move is", coming in the form of NCI data. Because each move is a separate line in the NCI, you get separate lines in the gcode output.

You will also see the same thing (redundant moves) in Z, when moving from clearance to retract planes.

I can think of two solutions:

1. Make an enhancement request to CNC Software, for an enhancement to the Toolpath Filter, to concatenate linear moves in the NCI.

2. Add some code to your Post in 'ppost$', to load the NC File as a String Buffer, and scan through the code, line by line, and only writing the "final" position moves. (Make the Post concatenate the moves.)

You make be able to do this "during regular NC output", but it won't be easy. 

[mkd]

So, what's your filtering set to?

[Kampfzentrum]

13 hours ago, Colin Gilchrist said:

The issue is that the Post Processor doesn't know anything about your path. It only knows "what the current move is", coming in the form of NCI data. Because each move is a separate line in the NCI, you get separate lines in the gcode output.

You will also see the same thing (redundant moves) in Z, when moving from clearance to retract planes.

I can think of two solutions:

1. Make an enhancement request to CNC Software, for an enhancement to the Toolpath Filter, to concatenate linear moves in the NCI.

2. Add some code to your Post in 'ppost$', to load the NC File as a String Buffer, and scan through the code, line by line, and only writing the "final" position moves. (Make the Post concatenate the moves.)

You make be able to do this "during regular NC output", but it won't be easy. 

Thanks. Yeah... Option 1 seems a bit more up my alley, I've never modified the post - where does one even learn to do that?

[Frank Caudillo]

6 minutes ago, Kampfzentrum said:

Thanks. Yeah... Option 1 seems a bit more up my alley, I've never modified the post - where does one even learn to do that?

From the guy that posted that, lol.