Another plasma component...

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.

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

phillc54 wrote:

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.

I'd probably suggest or recommend not doing it that way around as it will lead to some confusion (but each to their own)

I'd suggest using an option ....
M3 must always be issued to start the torch, and perform the touchoff etc, but then if you want to turn off the torch early you need to issue an M62Px anywhere after m3 and where you want to turn off the torch an m63Px..... motion will then continue until m5 where the xy axis decelerates to a stop and the z-axis is retracted.

this is because M62 is output on and m63 is output off.... yes I know the signals can be inverted, but if you forget to add an m62 later your torch probably won't fire..... unless you automatically reset m62 at the time of m5

autocorrect is changing m3 to me!!!

yes there are two things being discussed here and they are not the same

one is m5 which is not working correctly (motion must stop before enacting m5)

and the other is the ability to via sheetcam issue an m63 (or m62 if that is the way you want to go) before the overcut to stop the torch firing before it decelerates to a stop which will prevent the overburn divot at the end of the cut where m5 is implemented

Phill,

You probably already have this covered, but before you release the M62/63 version, just a reminder: When I mentioned the use of M62/63 codes for turning off the torch at the end of cutting a circle last week, Rod mentioned the concern below:

rodw wrote:

You have to include M5 to turn torch off becasue if its left to M62/3/4/5 if you hit estop, the torch will continue to spew fire which is not pretty if the breakaway activates and the inverter is on the opposite side of the table to you. Ask me how I know?
It would be possible to AND2 the motion pin with a digital pin to enable the torch on relay but that breaks the sheer simplicity of plasmac. there is a motion.distance-to-go pin but I suspect it is for a specific segment, not the whole movement from M3 to M5

Steven

I think the decision for plasmac becomes whether it remains nice and simple and works off M3/M5 or whether it should add an additional command to enable/disable the torch from Gcode. One way or the other M3/M5 must be part of the torch enable otherwise the torch can remain firing after you hit estop!

When I reviewed some of the material Phill said he modelled some features off, other commercial systems do use gcodes to enable the torch so the gcode can disable the torch independent of M5. I did wonder at the time why Plasmac did not include the gcode torchenable.

Phill's got two commercial testers. John only cuts thin material around 2mm. Stefan cuts anything up to 20mm. I kinda think Stefan is finding some issues that were not discovered earlier by John. I know that the few parts I cut from 16mm did open whole new can of worrms.

I'm not sure I've cut enough to make a recommendation one way or another except to say Stefan has probably discovered why commercial systems can enable/disable the torch from g code. It not that difficult to add this feature using hal components without changing the core plasmac code. Its just that Phill has been spoiling us