Remember Arc Lost position

[beefy]

Example for divot prevention you turn off the torch (deliberately) a short distance during before the cut path ends. Therefore you are turning off the torch DURING motion and you do not want the loss of Arc OK to stop motion. That is completely achievable with cam by inserting M206 (THC Off)

+M11 (provided you fired the plasma with M3 M10)

Cheers Rob,

I'm actually very aware of that but I do have a question for you regarding it so I've started a new thread in the plasma section. Don't want to "contaminate" this one with an off-topic subject.

Keith

[shad]

Example for divot prevention you turn off the torch (deliberately) a short distance during before the cut path ends. Therefore you are turning off the torch DURING motion and you do not want the loss of Arc OK to stop motion. That is completely achievable with cam by inserting M206 (THC Off) just before the torch is turned off. Then any THC Up/Down signals are ignored and loss of Arc OK will not stop motion.

Hello Keith. You right. I forgot about the M206 command for disable the THC and think about how to solve this problem
I can not get used to the fact that the M205/206 disable THC (wait arc for move and AVC) globally
Maybe it's the legacy of the Mach CNC, but all my controllers has adjustable ArcLost timer. It's allow to delay turn off the ArkOK signal to the CNC for prevent stop of the motion. "M5" command also finish this timer.
Just I did some tests too and found that if you turn off the torch for a few milliseconds before the end of the cut and did not stop the motion, the isotherm process is sufficient to finish cutting and reduce divot.
Of course in previous post I said about the deliberately arc lost event and we don't need to store arc lost position.

[cncdrive]

Guys, I have just talked to my API developer collegue about the Arc lost position and he said that this is already implemented.
He said (which I also knew about as we discussed about this earlier, but I totally forgot it) that if the ArcOK signal gets lost then the target position for the motion controller will be that exact point,
so what will then happen is that the motion controller will stop the motion with decceleration and then will move back to the position automatically where the Arc was lost.
So, this is already implemented in the current official release also.
So, you can just wait for the Idle state of the controller when the Arc goes off and then you can read the coordinates from the DROs, because the machine will be standing on the exact coordinates where the ArcOK signal got lost.

[Robertspark]

Wow! Thanks.... one for the website advertising features there plus users manual. Thank your api developer. Don't think there's no one else offering that built into the motion controller plus control software

[shad]

It's great!
I can not wait for the new version for testing !!!

[shad]

One thing - IMHO this events must be issue only if THCON and controller state is Run

[beefy]

Balazs,

that is fantastic. I'm still in shock that there is now a great Mach3/4 alternative with fantastic ongoing development.

For plasma cutting and lost arc I would imagine that the exact location (XY co-ordinates) when UCcnc lost the Arc OK input signal, would be slightly PAST the actual position where the arc really turned off. My reasoning is that it does take a small amount of time for the plasma cutter to "see" the lost arc, then de-energise the Arc OK relay, etc. Of course faster cut speeds will have a more noticeable distance.

Therefore, I'm thinking a great feature would be to have a DRO where the user can enter a distance value. This distance value is subtracted from the recorded lost arc XY position ALONG THE CUT PATH. The new XY position you have can be used as a torch refire point so when a dry run is being done the torch is automatically fired BEFORE the recorded flame out point.

Opinions anyone ?

Keith.

[Robertspark]

I think that is going to be difficult to do...

As soon as arcOK drops out (provided thc is enabled) I suspect that the motion controller triggers an axis step count, so that once motion has stopped, the motion controller can backstep so many steps X, Y (presume, z, a, b, c too?) To the location that the arcOK dropout....

Not sure if the motion controller knows where it's been prior to this, but I'm sure Balazs can advise.

Can Balazs also confirm if the lost arc keeps track of all axis positions or just the X and Y (as some of us use a rotary axis too (A)

Can Balazs also confirm that the backsteping conforms to the relevant axis max velocity and acceleration settings too (ie we are not going to end up with lost steps)

Thanks, just trying to understand the full operation and any limitations of the system

Looks like we just need to write an automatic restart macro.... anyone got any suggests about how to flag were are in a lost arc situation and we've still got gcode lines left..... we can then run a touch off macro, re-enable, thc (although it should not have toggled off), touch refire, and run from here.... presuming we then don't need the pierce delay... given we are refiring very close to the last known lost arc position... allowing for the plasma kerf end of cut radius (0.8 to 1.2mm dia? ... amps, consumables and machine dependant)

[beefy]

Hi Rob,

I'm hoping that in the motion controller data memory the "moves buffer" can retain enough already finished moves to be able to backtrack enough distance. The fact that it already backs up to the flameout point suggests this is already being done, so maybe it's just a matter of doing it a bit more.

Yes an auto restart macro is what I'm aiming at with this feature suggestion. Not entirely sure at this point how to do that at this point because my feature suggestion records a specific XY point, and not the start of a gcode line. A macro loop repeats relatively slowly and so repeatedly testing for the recorded XY point means it could easily be missed. Perhaps we'd need to do something like test if the current XY position is within a certain distance of the recorded XY point, and if so fire the torch. The macro would also have to take into consideration the current feedrate because at a specific feedrate the torch can move a certain distance in the time between macro loops.

Did I make sense with all of that. Hoping I'm conveying what's in my head to understandable print LOL.

Hmmm, something else has just popped into my head. It may be good to have TWO XY positions we can take advantage of. One is the start position of a dry run (after the flameout) and the other is the already mentioned torch refire position. I'll explain why.

In gcode a 2 metre long line is one single command. The run from here would only let us go back to the start of the 2m line but what if the flameout point was 1.8 metres along that line. We want to start the dry run say 30mm before the flameout position then fire the torch maybe 10mm before the flameout position. Because a Run From Here cannot start at that point, this may have to be a new function within UCcnc.

Am I overlooking any simpler solutions ??

The macro order of things would need to be a little different from what you mentioned. THC would need to be disabled until AFTER the torch has been refired and thus the Arc OK signal re-established. Remember if THC is on, we cannot have a dry run because you can't have motion without Arc OK.

We also don't need to worry about pierce delay or the kerf width. The torch simply does a dry run at cut height and the torch is refired while travelling in open cut. As for the kerf width UCccn doesn't know anything about that, it only knows the "controlled point". The kerf width/diameter is just something the cam software uses to generate the path. So if the kerf width/diameter was say 2mm and the torch was at position X3 on a straight horizontal run then the cut is already up to X4 (X3 + half of 2mm kerf). So it automatically sorts itself out, no need to include it in an auto restart macro.

So in a nutshell an auto restart sequence would be:
1) Disable THC to allow motion without Arc OK
2) Go to dry run start position (e.g. 30mm before flameout point)
3) Touch of and move Z to cut height
4) Commence dry run
5) Macro loop monitors for proximity to torch refire position (e.g. 10 mm before flameout point)
6) Fire torch when proximity is found
7) Monitor for Arc OK LED
8) When Arc OK LED on, turn THC back on
9) Watch with the most evil grin as we enjoy such a great feature

Keith.

[Robertspark]

Keith,

Yes, that made sense to me.

Couple of points though...

In gcode a 2 metre long line is one single command. The run from here would only let us go back to the start of the 2m line but what if the flameout point was 1.8 metres along that line.

That one is not quite correct.... (providing you are in absolute distance mode...) because the g-code only gives the destination.... not the start point so if the flameout happened 1.8m along the 2m cut line, then the run from here would only tell the controller the destination
If you are is incremental distance mode, then yes, you have a problem.... not sure how to solve that one... other than run in absolute distance mode

The other problem can be feedrate..... because if you've set up the feedrate as a modal command, then it may not be available on your g-code restart line position.... hence you need to save the current feedrate before carrying out the touchoff etc, then add it back in before the g-code line (run from here) as you may (should) have a touchoff macro using G1...
Hence one of my questions below to Balazs was what feedrate does the motion controller send the machines back to the arcOK position, because if it was to use G0.... the G1 feedrate would be lost / over written from the current g-code line....

We want to start the dry run say 30mm before the flameout position then fire the torch maybe 10mm before the flameout position

Not sure if this will be classified as an exotic feature... and difficult to implement as you're obviously intending to get the torch back up to cutting feedrate before firing it. I'm accepting of a divot as the refire will obviously create one, but divot removal can be an expensive time consuming operation of diminishing returns.