UCCNC + Lost Arc + ARCOK + Neuron

[Robertspark]

Firstly I appologise for posting something about the Neuron on this forum, but as this issue concerns the Neuron and UCCNC I thought it best to post it here, given Andrew and Balazs frequent this forum I thought it best to ask the questions here to get a combined response about potential latency issues.

The Neuron Lite (+ pro) operate with UCCNC via a plugin, and the only hard wired interface (high speed) interface between the neuron and the UC motion controller is an input for the Neuron to lock the THC and inhibit z-axis motion.

All other functions and information are passed between the neuron and UCCNC via an ethernet connection and the Neuron Plugin.

Amongst other things, this also includes when the torch is to be ON / OFF and also when the ARCOK signal is recieved by the Neuron.

The torch ON / OFF signal is not a big issue as I believe I have a way of dealing with any latency + overburn issues and using M10/M11 via the motion controller directly + the UB1 breakout board (happy to go into in a seperate thread if someone wants to know).

The ARCOK signal is the one that is causing me some thought at present with regards to "potential" latency / signal delay and also the use of UCCNC's very good (exact) lost arc position backup.

I was wondering what the potential delay was from the time the Neuron recieves a change in state of the ARCOK signal input to the time that the UC Motion Controller becomes aware of the lost ARCOK signal and can respond to it.

The reason why I ask this is because of a few things

1) ARCOK provides the pierce delay before X/Y motion begins .... if this signal is delayed motion may be delayed to begin (I suspect that this is an internal function within the UC motion controller wating for the ARCOK signal to be recieved).

2) [as I understand it] ARCOK if lost during the cut (M3 or M10 active) will allow the motion controller to internally record the lost arc position precisly, decelerate + stop the X + Y motion and backup to the exact postion of where the ARCOK was lost before a restart can be issued [All done within the motion controller]. If there is a delay in recieving this ARCOK signal because it has to be forwarded by the Neuron, back via ethernet, via the plugin loop, via the buffer and out the motion controller, the exact postion of the lost arc may be inaccurate given there may have been some delay in recieving the signal.

The fix I was wondering was to wire up the lost arc signal to both the Neuron and to one of the UB1 inputs, that way the UC motion controller AND the Neuron THC both recieve the signal at exactly the same time.

What do you think, is this a non-problem or a potential issue?

I'Il ask this question also because I've seen some comments about lost arc and the backup and restart not happening in the right location, could it be possible that the reason for this is latency in the UC motion controller recieving the ARCOK signal from the neuron via ethernet + plugin + UCCNC buffer? hence the restart may be on the wrong line or wrong location (slightly)?

[cncdrive]

Hi Keith,

The delay between receiving the emulation signals and sending them and processing them up can have a delay upto 20msec.
These commands are not put into the motion buffer, so the only delay what will be there is how fast the packet gets from the UCCNC to the motion controller via the ethernet port.
And ofcourse the time the signal is sensed and sent to the plugin from the Neuron THC controller, but I do not know how much time is this.

Since the UCCNC requires 20msec packets latency to work properly, this is the max. time it can take, otherwise if this time is longer then the UCCNC is already not working properly.
In practise this time is lower, for example on my computer the latency graph goes up only to upto about 6msec as worst case and so on this particular computer the worst case delay is 6msec for any packets reception.
The only real realtime solution for the THC signals is to receive them through the motion controller pins, in any other cases when there is a communication channel inbetween is not real realtime and the question to decide is basicly if the max. delay is long enough to cause real world problems or not.

As far as I know Andrew managed to recover the arc loss position within the plugin pretty good, but there is one problem, with arcs, that the plugin can't know if the arc was lost on the very end of an arc/circle, because the plugin has no information about that. And so if the arc was lost there then the next cycle start on the very end of the arc will cut a full circle, because then programmatically that will mean a full circle for the software.
The UCCNC has a protection against this issue which protection was added a few versions back when we faced this issue, but it is not possible to add this to the PC side,
because the arc lost recovery with the NeuronTHC is handled by the plugin (because it is using the vitual THC signals and not physical I/O pins on the motion controller) and not by the UCCNC and so the software has no idea about to what point the plugin will move the torch back.

I discussed with Andrew that the solution is to parse the g-code file within the plugin and the plugin collects the position and line ID of the stopped line, so the plugin collects and has the recovery line ID and the position, so it can read that g-code line and if it was a motion then it can get the XY endpoint coordinates info of that line and can compare if it is an arc and if the stop point and the arc's endpoint are within one step and if so then it can jump to the next g-code line to do not execute a full circle incorrectly.
The only case when the plugin will be unable to decide and resolve this issue is when a full circle is programmed, because for full circles the startpoint and the endpoint are the same,
so the plugin will not know if the cutting of that full circle has just started or is just ending. So, we do not see a solution for full circles, however any good CAM softwares can break up full circles automatically to 2 halves or 4 quarter arcs with their post processors and so then this is no more an issue.

[beefy]

Hi Balazs,

that was Rob that asked that question by the way, not me

I suggested a new feature 2 or 3 times to deal with the potential issue of latency in lost arc response, but I never got any response. Now would be a good time to bring it up again.

Even if UCCNC has super fast reaction time when the Arc OK signal is lost, and it records the XY position at that point, I see it being possible the the recorded XY position may be past the true flameout point. Reason is it may take some time for the plasma cutter to remove the Arc OK in response to a flameout, and in that time, the XY axis are still moving.

Therefore my suggestion was a means of subtracting a user definable distance from the RECORDED flameout position. This distance would be back along the cut path and would be used to restart the torch from the TRUE flameout location.

Hope that all made sense. Would this be a difficult feature to implement ??

Keith.

[cncdrive]

Hi Keith,

Ahh, sorry, it was probably too early in the morning and I mistaken Rob with you.

What you asked about is not easily applicable. I'm currently not even sure how to make it, because what the motion controller see is a positions definitions in time and the length of this time buffer is limited,
so the same amount of buffer lenght means different distances of travels with different feedrates. With low feedrates the distance is low, so there will be always a feedrate value point where below that the controller would not see further and could not go back in position.
And also with different feedrates this defined distance should be different in my opinion, because the time delay is about the same always and so the travel in the same amount of time with different feedrates gives different distances, so giving a constant distance to go back is far from perfection, it would be perfectly precise with one feedrate value only when the travel distance with the feedrate matches the set distance.

[Robertspark]

Balazs,

20mSec latency + whatever the delay is for the Neuron to pass through the signal of the ARCOK

Where has 20mSec (50Hz loop) come from, I understood the loop to be 20Hz, or is this just for screenset elements + macroloops?

are field elements updated at 50Hz or 20Hz? {this is only the work co-ordinates fields I'm interested in} because these are what the Neuron (was) using to record the position when the arc was lost
Presumably these may not reflect the actual position of the machine at that exact moment of time because of the buffer.

_____________________________

at a theoretical (target) maximum cutting feedrate for semi-commercial plasma cutters at say 600 inches per minute, that delay 20mSec is ~ 5mm of travel.

at a "book" maximum feedrate for my plasma cutter of 400 inch per minute, that delay is ~3.4mm

at a more "normal" feedrate (that I run) ~ 250 in per minute that delay is ~2mm.

The kerf is about 1mm wide, hence the there is about a 0.5mm overcut in front of the cut end position, and a 0.5mm overcut before the pierce position. {the kerf can be smaller} hence we could be looking at an uncut gap of 1mm to 4mm that has been missed when an arcOK signal is lost and the arc OK signal is delayed to be recieved by the UC Motion Controller by the Neuron?

________________________________

Would it maybe therefore not be better that

1) the neuron did not do cut recovery, but left it (in part) to UCCNC / UC motion controller to back up to the right / exact location.
2) the ARCOK was wired to both the Neuron and to the UC motion controller so both get the signal instantly (as quick as is possible) so that counters and position referencing can happen correctly?


With regards to point (1) the neuron screenset has a cut recovery button on screen which brings up a series of dialogs asking for either a manual or automatic cut recovery (screenshots below). I presume that in automatic mode the neuron will pull the feedrate, X,Y,A axis information from UCCNC once the motion controller has backed up to the lost arc position?

________________________________

I hear and take Keith's point about inherent latency of the plasma cutter.

This is the time it takes for the arc to actually be lost and the plasma cutter to realize that the arc has been lost and to then close the relay within the plasma cutter.

Before the UC motion controller or the neuron gets this signal.

Other than having a look at the specifications for the ARCOK relay within the plasma cutter, I would not know where to start because at high feedrate as can be seen a 20mSec delay may be between 2 and 5 mm of travel.

On at least one chinese plasma cutter I've seen a really big chunky relay being used for what appears to be the arc ok function.... big chunky relay .... big coil to energise slow to respond. not like a signal or reed switch relay (sub 1mSec response to make / break).

Keith is correct that it may be beneficial to have a setting to allow the plasma cutter to backup an additional distance (time setting based [say 0 mSec to 2 Sec] which would allow for the machine to automatically back up an additional distance along the cutpath if possible which would account for this "inherent" latency of the plasma cutter.

What do you think?

Thanks for taking the time to read my waffle + respond.

Rob

[cncdrive]

Hi Rob,

What I think is that the whole thing fails already on the very first step.
The very first step is to sense the arc ok signal and you can't do it with 0 latency, because it is a massive and noisy signal.
I'm sure that at least 10-20msec low pass filtering is required to properly sense the signal and to create the on/off digital signal without getting false triggers.
You wrote that you get 2-5mm travel in 20msec, so the whole thing fails then in this very first step, because then the machine already overtraveled when the signal is even sensed and created.
So, I think to fully automatically accurately recover from an arc loss is basicly impossible. Even if the whole system is fully realtime the whole process fails on the very first step, the sensing of the signal which can't be realtime.
All the further delays in the system therefor do not really matter, because the arc lost position can't even be sensed instantly.

I think that the only way to properly recover is the manual or half automatic way.
The manual way is to manually move to the point and move the line pointer back with the RFH.
And by the half automatic way I ment what you described to have the ability to moveback on the path in a timeframe, e.g. 0-2sec.
I don't know how easily or hard is to implement this moveback, but will ask my collegue about it, but to add this feature we will sure need some time,
because as I posted previously the API development is currently frozen, because we working on the G41/G42 and this requires large changes in the software and we want to avoid problems,
which could occur if we start to working other API and C# software part related things the same time.

And answering your question, the DROs are updated with 50Hz, all DROs. (20msec)
I'm talking about the values behind the DROs when you query them which is different than how fast they may update physically on the screen.
Even if a DRO is not visible it's value will update with 50Hz. And even if a DRO updates slower physically on the screen it's value which you can query still updates with 50Hz.
So, what you can query from macros and plugins is the value of the DRO and that always updates with 50Hz, this is true for all DROs.

[Robertspark]

Thanks again for your reply Balazs

My interpretation of the lost distance came from feedrates of 600ipm (15,240mm/min), hence 254mm per second

But really this is pushing machine extremes in my opinion and would only be used if you had a big plasma cutter (high amperage) and was trying to cut thin plate with it.

If you were lucky enough to run acceleration of 0.3G (which seems to be the defacto plasma acceleration target), ~3000 mm/s^2, your minimum radius possible would be 21.5mm (hence we are also talking big tables here), and your distance to accelerate / decelerate would be 10.75mm

I would think that 250ipm is much much more common or slightly slower [200 ipm] (hence less following error), at ~106 to ~ 85 mm/sec hence the latency error distance would be much less.

I think the hypertherm plasma cutters will be very quick to detect the lost arc condition, and to relay it out but I don't know how quick (need to think of a way I can simulate + time it on a scope), it will all depend on the machine in use. In my opinion UCCNC can only react to the information it has so the sooner it gets the ARCOK signal state change the quicker it can do the things it needs to do at the start of the cut or if the arc is lost during the cut.

I expected that your API department would be busy on G41/G42 (which will be a big change and affect + be of benefit to more users than just plasma users), don't worry about timescale at the moment this is just a discussion about issues (or potential issues) there is no need to knee jerk reaction of doing something. Best to maybe understand the limitations of all systems in play (plasma cutter, neuron (if used), UC motion controller, UCCNC) and how they work. Have a discussion about it with more than just me, you and Keith to see if there is a wider issue or if it is a non-issue from others.

The plasma cutter machine side latency (if it exists) will affect all motion controller and stand alone THC control manufacturers the same under lost arc recovery.

[cncdrive]

Hi Rob,

Yes, I calculated that you talking about 10...15m/min feedrates.

I would be very surprised if you could sense that signal and output the digital arc OK signal below a 10msec latency, but it would be interesting to know what a plasma unit manufacturer or their datasheet have to say about this.
It would be also interesting to know what kind of output a plasma unit has for the arc ok signal, because if it is a mechanical relay then the relay switch over time is in the 10msec time range.

[Robertspark]

I'll take the cover off mine tonight and have a look at the PCB's (I still have two hypertherms.... a PMX350 and a PMX 45 (nonXP)), why 2... no idea, couldn't sell the PMX350 for less than I thought it was worth, still good for fine cuts and thin plate, served me well.

[shad]

Hello!
I'll try to explain how it works in Neuron.
Neuron has 15 msec time intervals between packets during operation.
5 msec debouncing interval for all input signals, include ArcOk from plasma cutter.
This is the maximum 20 msec delay between changing the state of the ArkOK input and the time when plugin will receive this information.
When the plugin receives this information, it saves current XY position using UC.GetXpos() and UC.GetYpos() API functions and switches the THC arcon virtual signal off. Machine stop with deceleration.
Now we have arc lost position (Of course this is not an exact position due to the delay, but very close). This method work fine in most situations, but…
Balazs describe above about issue when arc lost position very clear to arc end position.
UCCNC has internal moveback future on arc lost and you know about this. It’s safe from this issue, because now when running g-code in the UCCNC there is a protection, the protection is that the motion can't stop at the very end of the arc in other words if it does stop at the very end of the arc then the line ID is incremented so the line pointer will point to the next line which's starting point is the same point as the end point of that arc.
Also moveback future works only when THC enabled. If during cutting THC will be disabled from gcode (M206/M205 on corners for example) moveback future will not work. Balazs promise to add new function in to the API for enabling moveback independent from THC ON/OFF state.
So in current situation using moveback future not bad, but there is a delay between switches the THC arcon virtual signal on/off. This is 20 msec. Not a big value, but in total gives a 40-50 msec delay.

What I think – is it possible to check on the every start - if current position on the arc is on the very end of the arc? If yes, the line ID is incremented so the line pointer will point to the next line which's starting point is the same point as the end point of that arc?
Just make it on start event, not stop?

Suggestion from Keith is interesting. We can calculate the back distance depend from feedrate, if will know about delay value – total delay in hardware and software, even have big chunky relay on the plasma cutter.