Thanks Gents, much apprciated.
I'm unfortunatly in that quandry of too many projects and PCB's to install at present (kid in candy shop scenario) + at a crossroads where UCCNC does most things (doesn't have G41/G42 yet, but it's being developed and I'm sure will be sorted shortly, alhough I suspect that most people who use a post processor will have no need for it). {I intend to have a dabble at creating something like hypertherms pheonix software... or at least the wizards for it}
I like linuxcnc as the more I dabble with it's code, hal and python scripts the more it makes sense to those who like full control of everything, and you're not limited by the disclosure / assistance of a motion controller or an external torch height control developer, however in my case, but CNCdrive and Neuron are relatively proactive.
Not sure which post of mine you've seen Rod, but if you're interested in the detail it's here:
www.forum.cncdrive.com/viewtopic.php?f=16&t=781
The one on plasma spider is just posing a single question over arcOK latency.
Although I know that this is not a UCCNC forum, it's one of those times that it may be possible to see what others do and given linuxcnc has the benefit of high speed direct interface (servo loop) it opens up the possibility of doing something similar if it does not exist already.
Both the Neuron THC and UCCNC / UC Motion controllers have a lost arc recovery function, both work differently and I suspect that the Neuron is adding latency to the system in the way that it works and my view is that it should probably leave the lost arc recovery to UCCNC to deal with (and just focus on controlling the z-axis)
The Neuron THC recieves all plasma related signals (THC voltage, arcOK, ohmic and floating head input) and passes them to UCCNC mainly for display on the screenset, along with it's current status (initial height sense, transfer, pierce, cutting, retract and idle). It has one high speed input (200mSec) which inhibits / activates the THC {M62/M63 control in LinuxCNC, but there are more syncronous marcos available in UCCNC}
If the arcOK signal during the cut changes state (allowing for 5mSec debounce in the neuron), it will send a signal as part of it's 15mSec packet loop to the PC plugin which will both inform UCCNC of the lost arc and save the current DRO's position (point in time).
UCCNC once it recieves the lost arc signal (or change in state of a hardwired ArcOK during M3/M63 motion) will also record it's current axis position and decelerate the axis to a stop, and automatically backup to the lost arc position so that it can recover from the lost arc at that point .
The advantage with doing it directly within the motion controller is it knows exactly where it is the instant the ArcOK changes state (allowing for what appers to be about 60uSec debounce). The problem that I have is that the Neuron is forwarding the arcOK signal once it's done it's own debounce, ethernet loop packet, and to the PC plugin which may not be either on the exact line or exact position of the DRO's because of packet transmission buffers out to the motion controller, hence there were some reports of if the lost cut occured near the end of an arc then it was possible that instead of it recovering on the arc it would recover on the next line code segment or try to cut a circle ( because of the way G2/G3 IJK notion works and if you were unlucky that the recorded arc lost DRO position was at the end of the arc, hence "run from here" on a line of gcode will cut a circle and then progress to the next gcode line (arc / line))
Add to this that everything adds debounce into it, I was trying to understand how far out we were likley to be from where the actual incident occured.
For linuxCNC I'd suggest with a 1kHz (1mSec) servo loop your accuracy could get better as to where the lost arc actually occured, but simply recording the position + gcode line of where the ArcOK changed state (from True >> False) whilst either M3 / M4 / M63 / M64 are active. If you record this at the exact time it occurs (i.e. on the first servo loop pass, zero debounce), what you do is add your debounce to the signal by then checking on the 2nd, 3rd, 4th and 5th servo loop if the signal is still active .... if it is then you stop the gcode file, decelerate the machine to a stop, given that the feedrate is modal, send a G1 X____ Y____ A_____ (whatever) to back the machine up to exactly where the ArcOK changed state and run a "restart from here" proceedure on the correct gcode line (allowing for a IHS, drop to cut height and re-fire the torch, wait for arcOK and then move off the X/Y/A without pierce delay, allowing for a THC delay so that the arc stabalises [looping at the 2 plots posted previous, a safe bet would be a 1Sec delay before the AVC comes on line]).
Like everything there is always a catch..... it is very possible that you'll get a divot because the machine is refiring (hopefully) into or at the edge of a lost cut kerf and will need to accelerate back up to feedrate.
LinuxCNC has the advantage in that because of the servo loop it is possible that you can record information at exactly the time it happens (well 1mSec delay) AND THEN build in your debounce cycle so that if the status of the pin has not changed in how ever many loops then do something about it, if it does change then you had a false signal and it can be ignored (until it changes state again)
The delay in the arc actually stopping (i.e. the afterburn of the continuing compressed air (or other gas) flow) has an advantage in that hopefully it will extend the actual kerf to the point that the plasma cutters own internal latency changes the state of the arcOK output so that when LinuxCNC records the lost arc poistion it has a much greater chance of restarting in the right location and in or right at the edge of the pre-cut kerf.... dont forget the kerf is actually U shaped..... so there is a leading and trailing edge (radius) to the kerf too, it's not square like a hacksaw kerf (if you're cutting thick material then you have the other issue of the trailing kerf through the metal to consider too)
Sorry bit off topic, but hopefully it may give someone some ideas whilst I'm still in limbo between linuxCNC and UCCNC and getting to grips with linuxCNC's coding.
