TPG and Post Processor boundary

[aj5robinson]

Hi All,

It comes to my attention that we have at least two different understandings of the boundary between the TPG and Post Processor and we should thus get this sorted before the TPG developers start working. The differences are mostly around which side does the offsetting for the tool:

1) TPG's produce a path along the surface of the part being cut. The PP would then offset this path to the width of the tool and make sure it doesn't hit the part before converting to native machine commands. The advantage of this option is that the task of offsetting the path would not be duplicated among the TPG's however the TPG's would have less control over the position of the final path.

2) TPG's produce a path that is offset already. PP just converts this path to native commands for the machine being used to cut the part. Gives more control over the final path to the TPG's but introduces some duplication. The duplication could be reduced by adding support methods to the TPG API to assist in offsetting.

I thought that the 2nd option was how it works however some recent posts and comments I have seen possibly suggest the first option.

Please add your thoughts and describe any other alternatives.


Cheers
Andrew

[danielfalck]

The post processor 'filters' text and produces variants of the gcode/text file that the specific machine consumes. It won't know a lot about the geometry or strategy that is in the mind of the CAM user. It will mostly deal with variants of Gcode commands, number of decimals, line numbers in front of each line, etc.
So my understanding and previous usage favors #2.

[sliptonic]

I agree with Dan. I think all the libraries we're likely to use in the near future handle the tool offset internally. ie Libarea, Libactp, opencamlib, etc.

BTW, this video was posted to the #cam channel and shows how post processors are customized in the commercial application NX CAM. Way beyond what we're looking at now, but interesting none the less.

http://www.youtube.com/watch?v=GtR0e4E5 ... r_embedded

[aj5robinson]

Good to see we all appear to have the same idea. I just wanted to make sure earlier rather than later.

Interesting video there, good to know other ideas to make sure we don't make it hard to add features later.