Remember Arc Lost position

[beefy]

Thanks Rob,

always looking to have any oversights corrected and learn something new.

I did a very stressful stainless cutting job of 23 expensive sheets of stainless. My torch runs 0.25mm (yep quarter of a mm) above the surface on stainless and as a result I was always getting flame outs due to a tiny bit of slag getting wedged between the nozzle and the sheet. I did a LOT of mid cut restarts and now I know why some people don't like to cut stainless

The restarts didn't cause a divot, no doubt because the torch was moving at normal cut speed before the torch was refired. Any torch refire will be a dogs breakfast if the torch isn't first moving at normal cut speed. Not sure what you mean when you say:

"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."

With typical plasma acceleration settings, it will take hardly any distance to be moving at the set feedrate. In fact with every sharp direction change in mainstream cutting the torch is decelerating to almost a stop and re-accelerating to the current feedrate. So there's no difficulties getting up to normal feedrate especially with the 20mm distance (30mm minus 10mm) I used as an example. If there is the table is severely wrongly engineered and it would show up in every corner in a cut by the metal being "blown out".

Keith.

[beefy]

HIYA Keith do you remember teh auto restart macro I sent you (;-) That is teh easy answer. It works FINE here. I do it in Mach3 and UCCNC. IT has no divot as it restarts ON THE FLY . Teh one thing I did add to that is on teh dry run portion I reduced the feedrate to a set value and then step it back up after the torch fires. This does 2 things . The distance to refire is ALWAYS teh same as teh feedrate is ALWAYS teh same and it helps to not having a dwell for teh torch to penetrate teh metal on thick material.

(;-) TP

Thanks Terry,

I've picked up some very good info from you and Rob is just 2 posts. I like your bit about the reduced feedrate for thicker steel. All of my restarts used the same feedrate as cutting, but I was only cutting 3mm thickness.

I do indeed remember the auto restart macro you sent me, that one is not getting away from me any time soon, as I have it securely imprisoned for when I need its services. The idea I mention a post or so ago to monitor for proximity, came from your macro.

With your macro do you always have to go to the beginning of the last gcode line. What if you had a long long arc and the cut flamed out near the end of that arc. Would you have to start the dry run at the beginning of that arc again. THAT is one of the advantages I was seeing with this new feature suggestion, but now after what Rob mentioned I'm wondering if there is another way to achieve that.

It's also a good point what Rob mentioned about the feedrate.

Keith.

[shad]

Keith, look on my post viewtopic.php?f=16&t=143&start=10#p814
this is the simply code for restart from any position of the path.

[Robertspark]

Teh supporting macroloop simply waits for teh torch moving in dry run mode( THC off and M3 off) to CROSS teh refire point(+/-) and lights teh fire then reset THCon after a delay (if needed).

The problem with this is the macropump or macroloop delay ... and also you need to refire with m10 ... but by the time the m10 is initiated (at 25hz macroloop) the torch may have gone past the refire position

Any macro examples ? Even from mach3?
I've seen yours Andrew, but that is a plugin one and I didn't think I saw how control would be handed back over to uccnc gcode run from here, next line

[beefy]

Andrew,
thanks for the plugin code. I've been very busy (and knackered) the last couple of days so haven't had a chance to look into it but after a quick look I realised there's some code in there I don't understand yet. So I'll have to look further into that one.

Terry,
thanks for that info. So it does seem like there is room for a new feature if it's easy enough for Cncdrive to implement. Getting back to what I mentioned before, at present we need to start at the gcode block and if that was a two metre long arc and the flameout point was near the end of that arc, we have to wait a while for the dry run to get to the restart position. I see another POTENTIAL scenario with this where the touch off is done at the beginning of the gcode block and due to the long distance, unless the metal is perfectly flat/parallel to the XY axis the cut height may no longer be accurate at the flameout point.
So overall that's why I like the new feature idea, we could set a dry run restart distance PLUS a refire position BACK along the cut path from the flameout point. No need to go all the way to the start of a gcode block if the distance is quite large.

Rob,
good point about the macro loop delay but I see an easy fix. Increase the proximity distance based on the dry run feedrate, ensuring the travel could not PASS the proximity window distance within the loop delay time.

Keith.

[Robertspark]

Keith I had same thought about lost arc position and doing a touch off .... then I thought.... do you need to do a touch off? Given the torch should have been at the right cutting height when the flameout occurred.... then the torch is at the right height for an on the fly start....

Problem is... a 2m retract to start of line could be another issue.... unless you used that clever pcb plugin to correct for bed height (autoleveler).... and did a few touch offs

[shad]

Andrew,
thanks for the plugin code. I've been very busy (and knackered) the last couple of days so haven't had a chance to look into it but after a quick look I realized there's some code in there I don't understand yet. So I'll have to look further into that one.

Hello Keith! The main thing - after then arc lost issue you can start from any point of the cutting path if you have exact XY position of the path (of course if you not disturb motion buffer and not open new gcode file). I am never use torch refire on the fly. Just move torch to the arclost position (by G0 command) - turn on THC - command M3. Torch rereference on the part (or skip reference and move down to the stored cutting height) then controller turn on cutter.... Also operator can skip pierce.
But if you want to refire on the fly, you have to move for example on 10 mm before arc lost position. I have been ask to Balazs about adding new future. Add two buttons - Trace Forward (now this is not problem via Start button), Trace Backward (like reverse run) for jogging along cut path. I think it's will be helpful and I guess is not only for this task.

Anybody tested new UCCNC version? I mean return on the ArcLost position after then ArcOK signal was lost? Just I can't to see this future in the Release list.

[shad]

But being it stopped without acceleration the stop point would be the same as lost arc point and would not back up.

Hello Terry! I think stopped without deceleration is not good. I will try to make any tests too.
Or may be this future can be turned on/off?

[cncdrive]

The ArcOK lost situation is deccelerated and movement compensated back not with the Acceleration parameter acceleration,
but with the Compensation acceleration (Comp.accel) parameter.
The Comp accel parameter plays always in case something needs to be compensated, it is used for the backlash compensation also.
So, I think that you tested with changing the Acceleration parameter low leaving the comp.accel parameter high and this is why you did not notice the decceleration and the moving back, because it happened too fast.

Now I have just tested it and it works as I described, it deccelerates and moves back to the Arclost position.

[cncdrive]

Terry, the THC control was always coded into the microcontroller in the motion controllers, otherwise they could not work in realtime.
The arc signal lost is also detected by the motion controller and then the motion controller is who changes the target position to the arcOK lost position and then it just let the software know what is happening,
but the motion controller is who is in charge when controlling these things.

Maybe you thought about something else though, if so then I did not get the idea yet.