UCCNC + Lost Arc + ARCOK + Neuron

[shad]

All Powermax cutters uses relays for ArkOK signal. This is 5-10 msec.
MAX200Pro and XPR and other in industrial segment uses optocouplers - 1 msec max switching time.

[Robertspark]

Hi Andrew, thanks for the input.

So, Neuron has 20mSec latency, [5mSec debounce] + 15mSec packet frequency.

And UCCNC has 20mSec latency for the software signal loop back out the motion controller.... so the total delay (non machine side 40mSec)

Can we not cut this delay down by feeding the ARC OK signal into BOTH the Neuron {or any other stand alone z-axis controlling external THC} UC Motion Controller directly ?
Given

the physical inputs filter (RC) constant with the -5LPT motherboard is approximately 20usec. (not sure what other BoB's are like the UB1)
and the controller samples 3 edges to validate the signals.

http://forum.cncdrive.com/viewtopic.php ... unce#p5053

Is the time between samples within the UC Motion controllers not kernal loop speed? (or a divider of it? (1/2; 1/4; 1/16; 1/32; etc))

I am also concerned about the ARCOK signal at the start of the cut, before the pierce delay starts and if this is delayed getting to the UC Motion Controller, it cannot correctly start the pierce delay counter once the ARC OK is received and before X/Y/A motion starts (maybe it is a non-concern issue )

[Robertspark]

Out of curiosity, I have asked via PlasmaSpider what the latency of hypertherm plasma cutters may be between an arc being lost (+confirmed) and relayed out of the machine via the opening contacts of the ARCOK relay. Hopefully Jim Colt, or someone else in the know will answer.
http://www.plasmaspider.com/viewtopic.php?f=60&t=24069

I've also asked Weerasak at CNC Room about the input to output latency of the UB1 for input signals out of curiosity.

[cncdrive]

Hi Guys,

That is what I thought about the output relays. A midsize relay can do about 100Hz (10msec) range in switching and a small relay could do around 200Hz (5msec) range.
And this signal will also need some small debounce which is again a few milliseconds.
And as I mentioned previously I'm sure that sensing the signal and creating the digital arc ok output probably needs again at least 10msec.

Thanks Rob for asking Hypertherm and CNCroom about this, it will be interesting to see what they think about it.

And I have one more question is what overtravel is even acceptable?
I mean what is the max. overtravel value when the torch recovery/workpiece is still acceptable?
I'm asking this, because if it will turn out (and this is what I suspect) that the plasma units can't detect and switch the arc ok signal within 10-20msec then is that value still acceptable?
This would be an interesting question, because if it is not then is it even worth to try to shorten down the time delay between the arc ok signal and the UCCNC acting on it?
Because if that 10-20msec causes a for example 2-5mm travel because of the sensing and relay switching delays and for example the communications delay ads another 4-10mm, so a total of 6-15mm,
then does it makes any difference if the position is wrong with 2-5mm or 6-15mm?
Or we should just go on with trying to implement Rob's idea with the manually adjustable moveback points saving in a range of e.g. 0-2sec and do implement the recovery from those datas?

I think we should wait for Hypertherm's info to answer my questions, but I typed them down now to do not forget them.

[shad]

The physical inputs filter (RC) constant with the -5LPT motherboard is approximately 20usec and 3 samples give 60 microsecond. This is a very small value.

Can we not cut this delay down by feeding the ARC OK signal into BOTH the Neuron {or any other stand alone z-axis controlling external THC} UC Motion Controller directly ?

No, because all stand alone THC use ARCOK for start cutting sequence and only after pierce end send ArcOK (Motion) signal to the UCCNC.
Also Neuron try to minimize delay between pierce end and start motion on the XY plane. Firmware decrease pierce time on 20 msec (of course if pierce time not zero value )

[cncdrive]

The physical inputs filter (RC) constant with the -5LPT motherboard is approximately 20usec and 3 samples give 60 microsecond. This is a very small value.

Yes, this is why I wrote in my previous post that extra filtering is likely required for the plasma signals, especially if it has relay outputs, because this 60usec on the -5LPT is probably short to filter out the relay debounce, so the breakout board connected to the -5LPT have to have some larger extra filter time.

[shad]

Balazs, we will wait API function for enable moveback on arc lost in situation even THC mode off.
And please think about checking position when arc end issue before start code execution.
One thing - may be use extra, out of turn packet and send it to the motion controller immediately when THC emulation on/off?

[cncdrive]

One thing - may be use extra, out of turn packet and send it to the motion controller immediately when THC emulation on/off?

The THC emulation signals already handled like that. They are handled with "out of turn" packets, they are not put in the motion buffer, but are sent out and processed much faster, in between the motion control packets, this is why these functions can execute faster than how long the motion buffer is and how fast they execute does not depends on how long the motion buffer is.

[Robertspark]

Gents,

Having a think outside of the box.

Suggestion:

Instead of having a debounce sequence before recording the current g-code line and X/Y/A axis machine co-ordinates, why not record them as soon as the arcOK changes state (whilst M3/M4/M10) is active, and then carry out the debounce loop sequence (i.e. in the case of the neuron, if after 5x 1kHz loops the signal is still off, then issue the message to stop the machine, and backup to the exact loction where the arc was lost when the signal FIRST changed state {or you were informed by the plasma cutter})?

That way you record the location + gcode line at the soonest possible time (excluding inherant RC filter / BoB latency [hardware] latency)

One thing that was pointed out to me and I was reminded of was that don't forget that once you turn off the plasma torch, the arc can continue to burn for a tiny while longer because the compressed air (or other gas) will continue to flow (to cool down the electrode + tip). The plasma arc does not stop instantly.

Also if you are cutting thick material (but that would be at a much slower feedrate) then you have the inherant trailing kerf through the depth of the material.
Not the best example I know (its also with nitrogen):
http://image.thefabricator.com/a/articl ... trogen.jpg

[Robertspark]

Or another way.... (in the case of the neuron)....

given the neuron transmits a packet every 15mSec from the neuron to the plugin.... why not record the current machine co-ordinates + gocode line every 15mSec when the packet arrives from the neuron, but over-write replace that packet every 2nd packet.....

so.... if the arc is lost between the time that this packet is recieved and the previous one, then all you need to do is back up to the previous location stored when the last packet came in?

(don't think I've explained that every well and may need to write it in code)