QTPlasmaC with fourth axis - rotary

Round tube = no THC and no 4th axis, must have float switch or ohmic, makes work much smoother.
Square tube = some types/sizes would be just fine wrapping the total of all lengths (yes lengths ), without radius's, but most will not be comfortable work doe to extinguished arcs and/or torch hitting material.

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

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.

snowgoer540 wrote:

Currently QtPlasmaC handles nothing with "probing" in this mode. 

Then it could be possible to probe using Gcode like G28 or G32. The old fashioned way for plasma to probe material height.

tommylight wrote:

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.

Yes agreed. Hence my hunt for a decent solution. It is beginning to look like we can find a solution by using Z movements and the Sheetcam plugin combined.