outputting kerf offset as variable in post

With about a half day of work on sheetcam and learning some lua scripting, I’ve nearly replaced an old, multi-month project that basically does the same thing but has no graphical interface and lots of errors.

I’ve gotten most of the way through creating a post-processing file to allow sheetcam to output commands for a custom labview RTC5 laser galvo controller. An important feature that I can’t figure out is how to leave the kerf (outside offset on the outline and inside offset inside inner features) as a variable in the script instead of hardcoded into the coordinates. I’ve seen how to add kerf as a variable, but again, this must be set within sheetcam instead of leaving it as an undefined variable in the postprocesed file. For instance, I’m looking for something like the syntax “step X1-kerf,Y” Is there a path rule or another simple way to implement this? You can see from my postprocessing file that I’ve written a custom lead-in that steps from the center of a circle to the radius-kerf then begins the cut. For all other offsets, it’s not so simple. Using sheetcam’s lead-in, I do not see how I would add the ability to manually adjust kerf in the generated script file.

Another interesting thing is that I have no need for z-height dependence. Our laser focus is set externally. The only way I could remove the rapid and step moves was to set the rapid clearance, cut height, and pierce height to zero. This produces many errors though. Is there are better way to remove all z-stepping?

Thanks for the help!
Tyler

SheetCam does not currently allow you to use the controller’s built in kerf compensation. There are two reasons for this: First of all, there is little standardization between controllers on how the entry move is handled and in many controllers entry moves are rather buggy. This make it very difficult for me to write posts. The second issue is that kerf compensation on complex shapes gets very touchy. If you use a larger kerf that SheetCam expects, the geometry may not end up correct.

[quite]Another interesting thing is that I have no need for z-height dependence. Our laser focus is set externally. The only way I could remove the rapid and step moves was to set the rapid clearance, cut height, and pierce height to zero. This produces many errors though. Is there are better way to remove all z-stepping?[/quote]

Just ignore Z as you do in your post. Add this code as the first line in OnRapid() and OnMove()

  if&#40;math.hypot&#40;endX - currentX, endY - currentY&#41; < 0.01&#41; then return end

This will make sure you don’t get duplicated moves when SheetCam plunges.

Finally, for some reason, the first rapid move call always outputs an endZ of 0, but endX and endY are not output, and just left blank. I’ve checked and they are of type “number”. In all other instances the rapid move works as expected, but I cannot figure out how to remove the erroneous first line.

This is because the first rapid move on a 3 axis machine should be for only Z to move to a safe height before any X or Y moves. To do this SheetCam sets endX and endY to huge values, which the Number and ModalNumber functions ignore.
Add this code near the beginning of OnRapid()

if&#40;endX > 1e17 or endY > 1e17&#41; then return end

Thanks for the quick reply! What you say about kerf compensation makes sense from that point of view. I have definitely experienced weird things going on with the kerf in our other custom-coded scripter. I would guess it was difficult programming the kerf compensation so that the kerf is always offset on the correct side of the material.
The kerf widths I’m talking about are on the order of 80 microns down to 10 microns for the micromachining we do, so these are small corrections anyhow. I’m hoping that I can just compare two files, one with kerf and one without and calculate the compensation that was applied, making it adjustable in script. Certainly a hack, but it doesn’t require any changes on SheetCam’s end at least. Short of that, just rerunning the post-processor for different kerf values as needed would work as well – though would definitely change up our current workflow.

I ended up setting the first Z move to be ignored by setting a semaphore that only posts onRapids after one has been called – your logic statement checking for huge endX and endY looks better. Also, your hypotenuse method for Z moves would work great, but I noticed at least one case where x, y, and z were all being moved at once.

Thanks again for the help!