UCCNC + Lost Arc + ARCOK + Neuron

This is the place to talk about and share things related to CNC plasma machines using UCCNC

Re: UCCNC + Lost Arc + ARCOK + Neuron

Postby Robertspark » Thu Oct 05, 2017 4:14 am

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

:roll: :roll:
Rob

Einstein ― “If you can't explain it to a six year old, you don't understand it yourself”
UC400eth, UC300eth, UCCNC v1.2045, Neuron Lite.
UCCNC Macro Manual
Robertspark
 
Posts: 452
Joined: Sat Sep 03, 2016 4:27 pm
Location: Nr Liverpool, England

Re: UCCNC + Lost Arc + ARCOK + Neuron

Postby shad » Thu Oct 05, 2017 4:48 am

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.
-- Andrew
UC400ETH
UC300ETH-5LPT
NEURON Lite THC
http://neuroncnc.com/
shad
 
Posts: 197
Joined: Thu Sep 15, 2016 5:23 pm

Re: UCCNC + Lost Arc + ARCOK + Neuron

Postby Robertspark » Thu Oct 05, 2017 7:25 am

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?
Rob

Einstein ― “If you can't explain it to a six year old, you don't understand it yourself”
UC400eth, UC300eth, UCCNC v1.2045, Neuron Lite.
UCCNC Macro Manual
Robertspark
 
Posts: 452
Joined: Sat Sep 03, 2016 4:27 pm
Location: Nr Liverpool, England

Re: UCCNC + Lost Arc + ARCOK + Neuron

Postby cncdrive » Thu Oct 05, 2017 9:06 am

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.
cncdrive
Site Admin
 
Posts: 1221
Joined: Tue Aug 12, 2014 11:17 pm

Previous

Return to CNC Plasma

Who is online

Users browsing this forum: No registered users and 1 guest