QTPlasmaC with fourth axis - rotary

mariusl wrote:

The torch will not hit if the Z axis is driven by Gcode like the Sheetcam plugin does.

Of course, i was talking about the general use case that some types/sizes can work with no complicated/SheetCAM math. Just plain gcode wrapping.

LesNewell wrote:

Does anyone know how QTPlasmaC handles referencing when keep-z-motion = 1?

This feature is something I asked Phill for way back when. I use it for my spring loaded marker holder I 3D printed with a marker to make templates, mark wood, etc. I also have a spring loaded diamond drag engraving tool that I use as well from time to time.

Currently QtPlasmaC handles nothing with "probing" in this mode. Z is set similar to how you would on a milling machine. I literally jog Z down to a point that the marker/scribe is touching the material, and then zero the Z DRO. Works well since all of the Z heights are controlled in the GCode, and any irregularities in the material is absorbed by the spring(s). None of the code I run requires an M3 though.

I imagine the component would have to be modified to probe to find Z0 and then allow the G-Code to drive the Z movements. I'm sure it's not impossible though, I can confer with Phill and see if I/we could possibly add something.

I have a possible solution which at first glance appears viable in a virtual machine but I need to do some halscope plots on my table. I won’t have time to do that for a couple of days or so.

Unfortunately that idea didn't pan out. Another of those too good to be true moments...

Do you know if SheetCam can output the X/Y/Z moves in incremental distance mode (G91). That may work but I haven't looked too hard as I am not sure that it is an option.

Failing that it seems that we will need to inhibit the inbuilt height sensing and revert to G38 probing for tube cutting in this case.

 

Les, would you  have a typical tube cutting gcode file with two or three cuts in it that I could have a peek at.