UCCNC + Lost Arc + ARCOK + Neuron

[Robertspark]

here is another way building on my perious idea ....

given we are dealing with inherant latency

The neuron sends a packet every 15mSec to UCCNC plugin, so if the neuron pluging records the position of the work co-ordinates every 15mSec so say you you keep 6 machine co-ordinate positions + gcode line numbers (current, -15mSec, -30mSec, -45mSec, -60mSec, -75mSec)

And the neuron has an internal loop of 1khz (1mSec), if you add to the packet a loop counter number (i.e. a number from 0 to 15), this could be done as a hex digit (0x0 to 0xF)

This digit would signify if the arcOK changed state and exactly when it changed state as part of the loop (excluding debounce, exactly when it changed state)..... So say the arcOK (whilst M3 / M4 / M10 was active) changed state on the 4th loop between packet transmissions to the neuron, you know that in the ethernet packet that gets transmitted to UCCNC plugin via ethernet there would be a "0x4" ...

This would tell the neuron plugin that between the last packet transmission (4th 1mSec loop) the ARCOK was lost. This would allow the UCCNC Neuron plugin to interpolate the exact previous position of the torch (or very very close) exactly when the arcOK signal changed state.

This would alos allow for the Neuron to backtrack for any inherant system latency ...... say that we estimate with slow relays the delay + plasma cutter arcOK debounce is 50mSec, the neuron can interpolate the position of -50mSec loop stored g-code line + machine co-ordiantes against -60mSec and can obtain the exact position of where the machine was

The distance we are talking between neuron packets at 600inches per min = 3.81mm inaccuracy, if via plugin interpolation we are able to split this up into 15 counts, this would reduce the inaccuracy to 0.254mm .... anything less than 1mm should not be a problem because of the kerf width.

Obviously most of the time feedrates will not be this high so the inaccuracy will be even less.

The only problem that you will have will be interpolating G2 / G3 motion, but given you have the straight line position co-ordinates at 15mSec intervils, does it matter if you interpolate this via linear interpolation and not consider the arc as the inaccuracy will be very very small given we are now keeping track of exactly when the arcOK signal changed state (not worrying about debounce because the neuron will do that internally)

You will also need to allow for a debounce within the Neuron plugin (i.e. you will need to see two packets where the arc has been lost) this is becuse if you recieved a 0xC (12) packet this would not allow for the 5 loop debounce within the neuron 12 + 5 = 17, i.e. it will fall into the next packet.... so the next packet that landed would say 0xF (15) which incicates that the neuron needs to use the previous packet count of 0xC for interpolation.

if the next packet that landed from the neuron said 0x0 after the 0xC, then the decounce sequence within the neuron had cleared the signal and it was a false signal so the plugin would ignore the pervious change in state.

It is also worth pointing out that latency of the neuron may not be 15mSec, but slightly greater as the debounce at present may delay the ArcOK signal from being transmitted if it occurs before the 5mSec debounce has confirmed the signal has changed state and the next packet is sent out.

What do you think? (maybe I've lost te plot again).

[shad]

Rob,
Very interesting idea. I think I can try to check it on this week. Thank you!
One thing - in this method we still can return on the very end of the arc and UCCNC make full circle.
I hope Balazs can answer on my question about checking arc end issue before motion start. Now this condition checked after the motion stop.

[Robertspark]

I have been having a little more of a think:

It is possible that if you have a really noisey ARCOK signal (I have not seen / logged them and I don't have enough access to plasma cutters, but I know Andrew mentioned some really electrically noisey chinese ones [a customer is a customer regardless of whatever they buy...])

Lets say that an lost arc ok occured during the ethernet packet loop as position 0xC (12) of the neruon loop cycle, so because of debounce (5 loops, 5mSec) the plugin records 0xC and waits for the second loop for confirmation..... the second ethernet packet arrives and displays 0xF, this would offer confirmation that the previous 0xC was valid (because the ArcOK has been lost for the complete Neuron internal loop cycle) ...

if the second packet arrives and says anything but 0xF it must be ignored, and the new lost arc marker is stored for the next loop cycle.

The reason for this is because:
- if the next ethernet packet (NEP) arrives and says 0x0, this means that the ArcOK lost was a false signal and has now been cleared,
- if the NEP arrives and says 0x5, this means the previous 0xC was false and a new arc Lost occured at 0x5 (5) loop cycles.
- if the NEP arrives and says 0xC, this also will mean that the previous 0xC was false becuase it did not remain for the full loop time..

if the first packet says 0xF (ie lost arc occured at the same time as the 15 loop cycle between packets occurs), then it will also wait for the next 0xF to arrive..... there is a small possibility that this "may" be an error but the chances of two arcOK signals occuring exactly 15 loop cycles appart must be very small

One thing - in this method we still can return on the very end of the arc and UCCNC make full circle

The solution for this one is to maybe compare the stored co-ordinates against the g-code line co-ordinates if G02 or G03 is active..... if you parse the gcode line and X + Y are the same as the stored co-ordinates skip to the next gcode line?

[cncdrive]

The solution for this one is to maybe compare the stored co-ordinates against the g-code line co-ordinates if G02 or G03 is active..... if you parse the gcode line and X + Y are the same as the stored co-ordinates skip to the next gcode line?

This is the solution for the motion controller when it receives a motion stop event and this protection is already implemented, but we now talking about the neuron plugin itself making the determination of the arc lost position.
How can the Neuron do that?
It checks the arc OK signal and when it goes off then it reads the position from the UCCNC and the line ID.
At this time point the UCCNC knows nothing about the arc was lost, it only knows about it when the Neuron plugin calls the ArcOK off emulation signal via the plugin interface.
So, the position and line ID what the UCCNC sees as the stop point and what the Neuron reads out are likely not exactly the same. If there are small arcs or short lines in the code then even the line ID can differ.
Let's say the arc was lost on a full circle code.
When the Neuron reads out the position and the line ID then the motion is not yet stopped, so the position can be the end of the start of the full circle or the end of the full circle.
The plugin can't distinguish between these 2 cases, it can't know if the position what it measured is on the start of the circle or the end of the circle, the positon for these are the same for a full circle.

[attila0216]

Good Evening to all,

Quick question. Why UCCNC doesn't wait with motion till Arc ok issued. I'm having problem with Powermax 45XP cutter when first M03 commanded torch fires instantly, but after there is a 10 sec postflow from torch. During this 10 second if M03 commanded, Hypertherm has approx 400milliseconds delay( it looks more in reality close to 2 seconds) but UCCNC gives out motion before pierce complete so tube never cut complete.

Any solution,

Using plasma screenset Proma thc. Arc ok comes from CPC connector of Powermax.

[Robertspark]

Note this thread was specifically to discuss the NEURON Torch Height Controller interface with UCCNC.

That being said, have you enabled THC via either the screenset button on the run screen OR the checkbox on the configuration + IO setup screen and added the arcOK pin and port settings.

If so, it should wait for ARCOK (or transfer before movement).

[attila0216]

Thank you. At first i've built with Neuron lite this pipe cutter, but because want to use for rectangular tubes can't use Neuron as ignores Z commands from UCCNC. That's why swapped for proma 150. I didn't know i have to enable thc in order to use arc ok feature.

Thank you!

[Robertspark]

Interesting, I had not considered square tube cutting with the neuron.

But given the neuron just tracks the voltage, do you not think if you had a fast enough z axis it would not be able to follow the square tube profile.

[attila0216]

I've tried. Didn't work although Z axis very fast. Andrew sad won't work with square tube. With pipe is great i love Neuron, but for square unfortunatelly not good

[Robertspark]

Thanks for the info, I learnt something there.

I was wondering, what are you using the Proma for, and does it work?
I ask this because you are obviously controlling the z axis motion directly to track the output from sheetcam as the box section is rotated, but do you then still need the Proma?

I guess what I'm asking is can you command the z-axis and provide out of bounds axis control via THCUP and THCDN signals and over-ride the commanded axis motion at the same time? (I've never tried / considered this before)

I was thinking about this and you could probably toggle the Step & Dir signals from the neuron to the UC300ETH via a macro which would flip two (or 4) NC/NO relays which would allow for the Z axis drive to be switched between the two control systems.