Hi MD
You give me the impression you may be over estimating the role the post usually plays (from the posts I've seen) in the code efficiency or quality.
Simply put, for most operations the CAM calls the post for each move, one at a time, and the post just translates the request into a line of G-Code. For example, if Fusion calls the post with
onRapid(_x, _y, _z) the PP post simply appends a G0 line to the program. There shouldn't be a significant difference between drilling ops from CAM compared to the conversational code unless you have canned cycles disabled in Sprut. In this case Sprut will output each individual move instead of making a single call (plus subsequent location changes). This could also be expanded by the post if necessary but PP doesn't require this.
CAM offers much more flexibility for path optimization by the user so I'd expect the resulting code to be more efficient in terms of runtime for a more complex part. However, that doesn't necessarily correlate with fewer lines of code. On the other hand, for the purpose of making a couple of quick holes the conversational system is likely to be faster from start to finish.
The posts do perform some optimization and error checking but in the posts I've worked on there's not a great deal of "clever stuff" done there. The probing routines for example obviously require support from Fusion to set up the required values and call the post correctly. These calls are very like canned cycle calls, making the required data available (positions, overrun etc.) and indicating that a particular probing type has been requested. The post collects the necessary data and adds this information to a subroutine call in the expected format. The Haas post would use a subroutine like a P9811 with the required arguments and my own post would call a PP subroutine like
o<probing_x>. If done this way the business is not known to the post at all. It
could be programmed entirely in the post but the effort would increase dramatically.
I'm sure someone familiar with the Sprut post generator (Tormach) could set it up to use the subroutines already provided by PP. I have my own routines so I haven't checked those in PP in any detail but I'm sure they'd be usable by a Sprut post. However, probing would first need to be added to the Sprut application. Perhaps you should contact them (they could use Fusion as an example
)?
Step