Another plasma component...

robertspark wrote: how are you controlling the torch off before the end of the overcut?

I presume that the overcut is set in sheetcam??

how do you tell the torch to turn off early? (I use the equivelent of m63 Px)

With the G-code I dont program manually, I use Sheetcam for the code generation, I set the overcut in the sheetcam cut settings.

thefabricator03 wrote:

robertspark wrote: how are you controlling the torch off before the end of the overcut?

I presume that the overcut is set in sheetcam??

how do you tell the torch to turn off early? (I use the equivelent of m63 Px)[/quote

With the G-code I dont program manually, I use Sheetcam for the code generation, I set the overcut in the sheetcam cut settings.

but how does linuxcnc know when to turn off the torch early before M5? (before the overcut)

robertspark wrote: but how does linuxcnc know when to turn off the torch early before M5? (before the overcut)

Not sure, From my experience it does not turn off. The point of over cut is to continue cutting past the start point.

The problem we have been having is the torch is staying on when the delay is set and it is still firing when the z axis is retracting.

robertspark wrote: but how does linuxcnc know when to turn off the torch early before M5? (before the overcut)

I think there are 2 issues being discussed here. One is the delay at the end of a cut before turning of the torch. That can be done in HAL.
The other is what thefabricator is doing and turn the torch off while still moving.

As far as knowing when we get to the end of the cut, there is a pin motion.distance−to−go but I think it is just for the current line segment. I have not played with halscope and a sim to see what it really does.

The online version of PlasmaC has a problem where the Z axis retracts before the torch off delay has completed.

A version I completed this afternoon uses M62 P3 to turn the torch off and M63 to enable turning it back on. This version has not been pushed yet.

thefabricator03 wrote:
The problem we have been having is the torch is staying on when the delay is set and it is still firing when the z axis is retracting.

ok, that sounds like the sequence of code is wrong within plasmac (bear with me not trying to pee on anyone's parade and all may become clearer with a bit of explanation)

from what I understand is plasmac is fully controlling the z-axis from m3 to m5, where m3 will tell plasmac that it needs to do a touchoff, retract to pierce height, fire the torch, wait for arcOK (if puddle jump is not set) drop to cut height, and begin XY motion controlling the Z axis relative to the THC inputs ( voltage / THC up or down, and inhibit z-axis correction if xy actual feedrate relative to set feedrate drops below the set parameter, as well as finally detecting kerfs to inhibit z-axis motion)

at the other end is M5 which tells the torch to extinguish, but also retract the torch to safeZ

I suspect that you need to consider how m5 actually works.... M5 is done OUT of sync with motion.... same as M3. whilst this may at first seem minor you need to consider what this means with G64

when an m5 comes along g64 is ignored by the planner and motion comes to a stop before m5 is enacted. so there are actually 2 parts to my, and I suspect that maybe plasmac is only looking at one part.... plasmac needs to look at both m5 and motion stopped BEFORE stopping the torch from firing and retracting the torch.

I suspect that plasma is just looking at the one m5 input which is actually used by the planner to decelerate the axis to a stop before actually running the actual code with the m5 macro file.

note I am not a linuxcnc user so some of my terminology may be off.

the fix will be to use an AND statement for m5 and motion stopped pins / inputs. I suspect you may need to allow a delay to allow for plasma to implement the hidden m5 z-axis and torch off control or linuxcnc will move to the next line after my very fast with will probably move the torch to the next part before the torch has retracted