THCAD-10 + hypertherm 45 (nonXP)

Rob

Good discussion on grounding and non US power supplies.

Now for those of us that live in the US that does not have a national electrical utility or standard things aren't quite so simple. While most locals base their requirements off of the National Electrical Code (NEC) which is revised and published by the National Fire Protection Association (NFPA) it is often hard to know which edition of the NEC a building was wired to if it is not new construction. For this reason if you do not have the knowledge it is always best have your local utility (public owned ones usually will do this for free) or licensed local electrician check the grounding arrangement at your connection point (service entrance). This is doubly true if you have a 3 phase supply to your building because many utilities save transformer costs by using an "open delta" connection which can result in one of the phases being phase to phase potential away from the "neutral" conductor.

Most small commercial, small farm and residential properties in the US will have single phase power supplies. The typical utility transformer feeding this connection may have the center point of the secondary winding (neutral point) connected to earth ground. Then again at the building service entrance the neutral conductor will be connected to earth ground and the buildings safety ground wiring at one point. The problem most people that aren't electricians have is determining where the service entrance actually is. Most older installations this will be at main electrical breaker or fuse panel but you can't be sure unless you know what you are looking at. Now to illustrate why you can't count on this arrangement I will describe how all new construction and re connections must be done where I live. The service entrance is actually out by the road close to the property line (a variation of this in town has the utility meter and disconnect switch mount to an exterior building wall) where the utility meter and disconnect switch are located. The neutral conductor and safety ground conductor are connected together and to earth ground (ground rod(s) or other means) at this point only. The feed to each building then is four conductors: the two phase conductors, the neutral conductor and the safety ground conductor. The safety ground and neutral conductors are not connected together at the buildings breaker or fuse panel. The safety ground is usually connected to earth ground (ground rod(s) or other means) again at the buildings breaker or fuse panel.

A not unusual problem here is that actual connection between the safety ground and earth may not be that good. This is caused by poor earth conductivity or a bad connection or both. The bad connection problem is very real in many older installations. I lived for a time in an area that had poor earth conductivity and the utility would often require multiple ground rods or other means before they would connect a new service. If you had an older connection you needed to have the utility (or electrician) check your safety ground connection before installing things like TIG welders or plasma cutters.

My plasma cutter installation does not have a dedicated ground rod. My plasma power supply (Thermal Dynamics) has the work lead (+ connection) connected to a star or common ground point on my table. This star point also has a conductor going to the table slats, a conductor going to the work clamp and a conductor going to the conductive probing (touch off) circuit. I have not had any interference problems that I am aware of. One note of caution is that the reinforcement bars and mesh in my shop slab are connected to the building safety ground conductors at the earthing rod connection.

John

Thanks John for the insight into the US .

We drive earth rods in here if the earth fault loop impedence (Ze) is not what it is suppose to be (less than 0.35 or 0.8 depending upon the supply earth arrangement), less so on domestic supplies as the electric supplier will normally deal with it.. but we are in the land that never stops raining for long so the ground conductivity is not that bad as, and you never need that many rods / an earth mat that I've seen in other drier parts of the world.

Rob

Back on topic....

I was wondering... would some kind person who has a working THCAD be able to take a plot of a short test cut (like a 1" square that was done below), but this time, include for the arcOK signal in the plot please
{I have a discussion on latency on anther forum with regards to the ARC OK signal}



[/quote]

I can do that - but my guess it - the arc-ok happens at the first movement blip before the long run. (the z move to cut height from pierce height)

about 2.4 divisions from the left.

Robert, I went through my archive of screen dumps and found one for you.

I think I found your thread elsewhere. You would really need to increase the resolution of the halscope capture but it looks like the latency is no more than 2-3 ms. And yes, if you were wanting to recover on a lost arc, it would be possible to read the x-y coordinates at this exact point. I don't know how you would map it back to gcode though. You may not need to though as my plasma cutter tries several times to establish an arc so it might be enough to stop motion and wait for reestablishment of the arc on loss of ArcOK. There is some revised touch off code here on the forum somewhere where the torch is raised if an arc is not established at the beginning of the cut, the torch is lifted and a message displayed suggesting that consumables be changed.

I think this again confirms that much more can be achieved if the THC is embedded right within the motion controller as it is done in LinuxCNC.

Guys

Remember the steel plate will continue to burn for some number of ms after the arc extinguishes if the air supply isn't interrupted (usually isn't on loss of arc) so if table motion doesn't instantaneously stop the end of the cut may not be at the loss of arc location.

I don't know anything about the actual delay times involved for the ArcOK signal. On my system with a stand alone THC I know that with the delay set to 0 on thin material it still takes too long for motion to start resulting in an ugly pierce divot. I hope to have my LinuxCNC controller with the thcad using the external offsets branch to work before next spring.

John

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.

Robert, don't worry, I found both of your threads
FWIW, I tracked down the ArcOK relay datasheet for my Everlast plasma. the maximum on and off times are 10 ms but it seems from the plot I posted its achieving much better than that.

If you were lazy, you could add a software debounce using this component, linuxcnc.org/docs/devel/html/hal/rtcomps.html#sec:debounce
then you would know for certain how long the delay has been (eg. the length of the debounce you set):

I'm wondering if the external offsets applied to the X & Y axes could be used. I still don't know enough about what can be done in internally but perhaps you could:
1. Suspend motion
2. Command the X & Z to return to the original position
3. Wait until we get there
4. Somehow apply a X & Y offset to continue on its merry way without LCNC even knowing.
5. Restart torch and Resume motion
6. Accumulate repeated errors so that subsequent errors account for previous errors. Or do you reset the offsets once you get back to the position you stop at.

What I don't understand is say if a flameout occurs half way into a 12 inch gcode movement, how you resume the code from the intermediate position.

Rod,

Remember, most of my discussion is about arc lost (arcOK dropout), so this is when the relay deenergizes... And that is normally much faster than relay close time

For both 3msec and 5 msec close relay times (2 different Fujitsu products relay datasheets) I've seen 1 msec to 1.5msec release times.

With regards to the gcode, remember that a gcode line (any line) only gives the destination of the move.... So on a 12 or whatever inch cut, if you loose the arc, record the list position fast enough, stop motion, back it up to the lost arc coordinates, perform a restart on that gcode line it will continue to that same destination point.

Rob

Update on my cable wiring. I shortened the wires as to leave the aluminium foil around the wires and I used terminal 3 on the thcad-10 card but I did not connect the wire that Im calling a ground wire it has no plastic coating like the other 2 wires. But that wire that does not have plastic coating on it also rubs the aluminium foil that I wired into the thcad card and has continuity with pin 13. So if I use the foil wrap im am also connecting to pin 13.