forum.cncdrive.com

Hello Balazs!
Please add function in to the API for turn on moveback on arc lost future independent from the THC ON/OFF state.
Just now if during cutting THC off on corners or on the small holes moveback does not work.
Thank you.

Hello Balazs!
I see in the new release this function still not present...
Can it be unrealistic to do this?

Hi Andrew,

Sorry for the delay with this.
I discussed this with my collegue and said that this is basicly not possible to make, because if the THC is off then the controller do not even check the arcOK signal and then it does not know where to move back.
However the issue was that you can't determinate properly where the arc was lost, because the Fact is already 0 and the ismoving bit is already false when the back movement happening, correct?

My collegue adviced to have the anti dive feature on, so then there is no need to switch the THC off on small arcs and on sharp direction changes in g-code and he will check and try to set the ismoving bit to remain on when the moveback motion happens, so then you could check the coordinates of the arc loss position correctly and the moveback will then always happen when the arc lost, because you keep the THC on.

Hello Balazs!
Thank you for answer.
I think the better way for me will be use my Cut recovery method.
We have been a lot of tests for Antidive function and this does not work as we would like. Problems arise with lines that consist of a large number of segments (CorelDraw drawings for example). THC always off, because all time Acc/Dec.
And because of the arising accelerations/decelerations at the junctions of lines and arcs, the Antidive always turn off THC too, even where the direction of motion is practically unchanged.
It's work better if we set acceleration value for axis to 7000 - 8000 mm/sec2. But this is not realistic value for our mechanic.

Hi Andrew,

OK, but then what do you suggest to do?

Andrew / Balazs,

what about a macroloop/plugin that continually scans for the Arc OK LED being on after M3. This way it is independant of THC on/off. Is there any way this macroloop could access the moveback function in UCCNC after detecting loss of Arc OK.

Obviously the fact that UCCNC can reverse run to the loss of Arc OK position means that it keeps some of the PREVIOUS gcode moves in a buffer somewhere. If this buffer could keep enough distance of previous gcode travel path, then the macroloop could specify a distance to "go back" along the cut path.

Is any of the above feasible ??

I've been working with cad & Sheetcam to try and break long lines and/or long arcs, or complete circles, up into shorter lines/arcs so that if I have to do a Run From Here, I don't have to do a 2.5 metre dry run before I can fire the torch. It would be a fantastic plasma cutting feature if UCCNC had the ability to reverse run up the cut path, so that a user could just back up say 20mm from the flameout point and do a dry run from there then fire the torch.

Keith.

OK, but then what do you suggest to do?

Balazs, There is only one way and I have talked about this for a long time.
You have to add a special digital output control synchronous M code (for example M62/M63) , which can control THC ON/OFF (Automatic Voltage Control) mode for stand alone THC controllers.
It's allow do not switch UCCNC THC mode during cutting (to be honest, in my understanding to turn off the UCCNC THC mode during the cut is not entirely correct, but you did not give us a choice).
In this case all UCCNC futures will work like charm.

what about a macroloop/plugin that continually scans for the Arc OK LED being on after M3

Keith, now my cut recovery work just like you said. But main problem this is latency (plugin main loop and API to UC controller delays) on the hi cutting speed. And this latency is not constant value.
About reverse run - I agree with you, it would be cool

shad wrote:

what about a macroloop/plugin that continually scans for the Arc OK LED being on after M3

Keith, now my cut recovery work just like you said. But main problem this is latency (plugin main loop and API to UC controller delays) on the hi cutting speed. And this latency is not constant value.
About reverse run - I agree with you, it would be cool

Exactly, latency is the big problem with monitoring the Arc OK signal. Even if UCCNC has this as an internal operation running continuously, we can't control the reaction of the plasma cutter itself.

That's why I think the answer to this problem is a reverse run capability so the user can simply reverse run a few cm before the flameout point, than start a dry run from that point and then fire the torch.

Simple and VERY effective for mid cut flameout re-starts.

Firing the torch during a dry run would be much better than going back to the flameout position, firing the torch then starting motion. That will most likely leave a "re-fire divot" where the torch re-started.
That's why I always do a Run From Here to give me a dry run with the torch off. Problem is if the last gcode block was a 2.5 metre long line / arc, the torch has to go all the way back to the start of that line / arc, quite a pain in the butt and also very bad if the plate has warped with the heat of cutting.

Keith.

Balazs, There is only one way and I have talked about this for a long time.
You have to add a special digital output control synchronous M code (for example M62/M63) , which can control THC ON/OFF (Automatic Voltage Control) mode for stand alone THC controllers.
It's allow do not switch UCCNC THC mode during cutting (to be honest, in my understanding to turn off the UCCNC THC mode during the cut is not entirely correct, but you did not give us a choice).
In this case all UCCNC futures will work like charm.

Sorry, but I read this description like 10 times now, but I still don't understand.
There is M10/M11 if you need syncronous M code output, so I don't understand why that can't be used? What would be the difference for the mentioned M62/M63?
There is also the M205/M206 syncronous THC on/off output, so why that is not good?

Keith, now my cut recovery work just like you said. But main problem this is latency (plugin main loop and API to UC controller delays) on the hi cutting speed. And this latency is not constant value.

Yes, there is no such thing as realtime in a plasma application, but we have talked about this earlier, that because even the arc loss can't be measured realtime from the plasma unit the whole thing fails on the detection phase, the rest of delays by anything only adds to that.

Basicly my problem is that I totally lost understanding of what Andrew wants to do. I would need a clear description about what needs to be changed, because we talked about so many things already that now I'm really confused.

Reverse run can't be done now, because we working on other things and that would require lots of changes in code which we can't do now, because we don't want to mess up the software core code with doing so many changes in the codes the same time. What we could do now is minor changes or additions and this is not something like that unfortunately.

Basically my problem is that I totally lost understanding of what Andrew wants to do.

Balazs, I think you right. We can use M10/M11 commands for this too, just I am forgot about this
So in this case we do not turn off UCCNC THC during cutting and "moveback on arc lost" future will work perfect.
Thank you.