Advice on adding plasma torch height control

[OwenD]

Part of my job is selling and supporting CNC plasma systems.
Whilst I can’t help much with the low level programming, I thought I could offer some concept advice that hasn’t been taken into account in this thread.

Most CNC systems run a seperate movement and height control processor and a plasma cutter with a CNC interface (serial)
Maintaining the correct tip to work distance is critical to good cut quality and in many cases is as low as 0.5mm

The general workflow is
1: CNC moves to start point and signals height control
2: Height control lowers torch until tip touches job (resistive sensing or microswitch) and lifts to a safe pierce height (2-8mm depending on current)
3: height control sends ready signal to CNC which in turn sends start signal to plasma. A timeout sequence begins here.
4: Plasma starts and minitors arc until stable then sends arc stable signal back to plasma.
5: upon receiving arc stable signal, CNC waits a pre configured pierce time before commencing movement. Arc stable signal is constantly monitored. System must stop if it goes off.
6: height control checks arc voltage against vref and adjusts torch up or down until two match.

Where it all gets complicated is the following

The plasma system maintains a constant current, but the arc voltage will vary considerably depending on two main factors.
The first is tip to work distance (which makes AVC possible)
The second is cut speed.
A CNC system (like a printer) must vary it’s speed so that it can get good cut quality on curves and corners.
Most CNC controllers and/or nesting programs have several levels of speed reduction depending on radius.
When the torch speeds slows (for a corner), the arc voltage drops.
The AVC (height controller) sees this drop in voltage and lowers the torch to compensate which causes the torch to crash.
To compensate, the CNC system must have a configurable signal to turn off the height control (via M code). This is usually by distance and/or time from end of cut and also angle of deviation in the case of two adjoining straight lines.
The height control must also have facilities to recognise repeated tip strikes and raise vref in response.
Finally it must be adjustable for sensitivity and movement speed to avoid oscillation.

Hope this is of use.

Regards

[OwenD]

@owend
The other places that cause problems is crossing cuts and when the “slug” in a hole drops out.
In both cases the voltage drops causing the torch to dive.

[mawildoer]

Thanks @OwenD !

I haven't (yet) had much experience with CNC plasma systems, but really appreciate your input on the matter.

I hadn't actually at all considered that cut speed would vary the voltage so that's certainly something to look out for. Perhaps I can do that based on the move feed rate change or add additional M3 Sxxx codes in these sections. I'll look into it though and your advice is really appreciated.

As for the separate controller, that was my original intention (though with only a couple of GPIO lines), which perhaps would still be simpler given the difficulty of independent Z moves in the current setup. I do like however having a tightly integrated controller, which allows for things such as automatically varying the expected cut voltage based on the current program. It also means I can use the (already plentiful) stepper drivers etc... on the board.

I actually have another technical concern you could perhaps help with. I am worried about the EMI from the plasma damaging the controller and was wondering the level of shielding/protection used on industrial machines. I have heard of swathes of hobbyists having issues in the past with this one and damaging one of these isn't an inexpensive issue. What are your thoughts on the matter?

[OwenD]

On most “entry level” CNC systems, the feed rate and AVC settings are best adjusted independently of the movement GCode
The nesting software gives you the option of including feed speeds F**** or not.
Anything in the GCode over-rides the controller settings.
The reason this is often best done independently is that with air plasma you may need to adjust feed speeds depending on plate condition, material and complexity of part.
There is only one ideal speed which gives best cut quality for a given thickness, material and current.
However this speed is usually too fast for smaller curves because the “flame” lags behind the torch. On straight lines it’s not such an issue, but on curves the lag causes a cone to be cut.
The only solution is to reduce speed which reduces the lag, but also this reduces voltage causing the AVC to drop and also increases dross,
So depending on how many levels of speed reductions you have based on radius and line deviation angle, you typically end up running at a significantly reduced overall cut speed than ideal so that curves and holes are at least acceptable.
Part of this is because “entry level” machines running Nema 23 or Nema 34 drives simply cannot accelerate/decelerate fast enough to get the best hole quality. And if they could, the beds couldn’t control the inertia.
High end machines which do have integrated movement and height control systems run AC servo drives and rack and pinions and usually mixed plasma gases to enhance cut quality based on material type.
This alleviates most of the variables and allows the gcode to hold all the variables with much more predictable results.

In terms of EMI an RF interference...,
The controller and AVC are typically Opto-isolated from the plasma. The plasma interface has a voltage divider to reduce the arc voltage to a safer level for the controller (commonly 50:1).
Good installation also have a considerable ground spike.
Good quality plasma machines (Hypertherm) and controllers are really well shielded and give little trouble, but Chinese machines can be very bad.

[mawildoer]

EMI Testing

Just a quick update on this one. I've done some testing very specifically on the EMI induced in a shielded wire taped adjacent and in very close proximity to the plasma cable. This test cable is a CAT 6 Ethernet cable, where each pair is foil shielded and the whole cable is braid shielded.

Also note that I didn't actually conduct everything in the following order, but I thought it made more sense to present it this way.

Test Setup

I got some interesting results (and way, way more noise than anticipated).

Control

No wires connected to the scope (except the power cord)
Thanks dad for suggesting this one after a mammoth amount of head scratching

At a (extremely short) peak of ~-40v, I was already surprised by how intense this noise is. Note the scale of the chart is 10v/div and 250ns/div. This pulse however only lasted for less than half a microsecond.

Unshielded Cable

The cable's shield wasn't grounded and instead connected to the signal line of the scope. The scope's ground was earthed.

Peaks are well above 100v and noise is at least 3 microseconds

Shielding

Grounding the shielding substantially improved the noise. Apologies for a lack of photo, I will repeat the experiments tonight and upload another image of the shielded cable for comparison.

The shielding reduced the peaks to ~30v, but this also changed dramatically depending on whether the torch was grounded when the arc was initiated. I believe that preliminary a set of small ceramic capacitors to ground should suitably protect the drivers, but I think I'll be testing it with a stand along step stick and cheapo arduino first!

[mawildoer]

@mhackney said in Advice on adding plasma torch height control:

David, in thinking about this, could the M290 baby stepping be used to inject the Z height variation as an option #4?

This sounds like a pretty good entry point for me, as getting into the nitty gritty of the integral code base, especially given you intend to soon rewrite is somewhat daunting.

You said:

To make it work well I would need to rework the babystepping code to make adjustments more quickly than happens now, but that's desirable anyway.

How slow is it currently?

[dc42]

@mawildoer said in Advice on adding plasma torch height control:

How slow is it currently?

About 0.5sec + 1 move.

[mawildoer]

About 0.5sec + 1 move.

Mhmm you're right in saying that's going to be a problem.

My plasma is remarkably forgiving in terms of crashed into the part so perhaps I'll begin with a sprung torch (to ensure it doesn't crash too hard) and focus on the other axes while I see how either modifying the baby steps/DDA goes.

Thanks once again for the help

[moameen]

@mawildoer I have always wanted a cnc plasma cutter but the cost of purchasing one was too much. Now that I have my first cnc (MPCNC), I am very keen on adding a plasma torch to it. My MPCNC is running of a Duet WiFi as well and my 3d printer (Duet V0.6). I am really happy with the Duet and a plasma system running of the Duet will be awesome. My plasma is similar to the one you have in the pic, nothing fancy like the Hypertherms. Have you made any progress? I am willing to help in any way that I can. My coding skills are basic though, only arduino projects.

[dc42]

At the moment it seems likely that I will modify the firmware to support independent Z moves controlled by some sort of PID loop in February.

[HoLukas]

@dc42 said in Advice on adding plasma torch height control:

At the moment it seems likely that I will modify the firmware to support independent Z moves controlled by some sort of PID loop in February.

That would be a really great feature to have and open up a lot of room for experimentation. It may also be useful to be able to override the E-Axis as well through the same system, as that would allow closed loop control of pellet or syringe based extrusion systems where maintaining a constant pressure would be highly desireable.

I know that is not the topic of this thread, but if you do actually decide to implement it for the Z-axis, opening it up to also work with the extruders would be great. I would certainly like to use a feature like this!

[dc42]

Thanks for the suggestion. I'll think about how much i can generalise the present motion system without it getting too complicated. Currently only one DDA (which represents a synchronised movement of axes and extruders) can be active at a time. I was planning to support an additional DM for just one "axis" that can move asynchronously with respect to the DDA. The PID loop would setup the required correction in that DM and wait for it to complete, before sampling again and computing the next correction. But I guess I could support more than one. Complications will arise when the system runs out of moves, or when a pause is commanded.

[andymidtf]

@mawildoer said in Advice on adding plasma torch height control:

EMI Testing

Just a quick update on this one. I've done some testing very specifically on the EMI induced in a shielded wire taped adjacent and in very close proximity to the plasma cable. This test cable is a CAT 6 Ethernet cable, where each pair is foil shielded and the whole cable is braid shielded.

Also note that I didn't actually conduct everything in the following order, but I thought it made more sense to present it this way.

Test Setup

I got some interesting results (and way, way more noise than anticipated).

FWIW, I've been investigating making a plasma CNC as well, and have noticed

1. VERY important not to use a HighFrequency arc starting machine, these DEFINITELY will fry CNC electronics, pilot arc start are the one to use
2. Many cheaper Chinese plasmas have a s*** load of EMI noise, even one page goes directly to prohibit the use of certain plasmas (including the make of the one you are testing) with their CNC frame: http://www.langmuirsystems.com/plasma-cutters
   by the way, their FAQ has a load of interesting info too

For my part, I'm also investigating an inductive probe to do the z-correction, instead of Torch Height Control, because I would prefer to completely isolate the CNC from the plasma (that said, would still need to attach the torch on/off M3....), but am also worried about EMI, but directly from the arc - if the inductive sensor is to be close enough to be useful to change height at the nozzle... if the sensor gets affected, it will incorrectly change the z-height... not convinced yet that it would work, probably THC would be better as is "spot-on" the nozzle...

Cheers!
Andy

[ddt154]

@andymidtf - Very interested in this topic. I'm doing a DIY CNC Plasma table and was planning to use a spare Mach3 controller. Now, I have 2x 3DPs with DuetWiFi (Duet 2 series) controllers and a spare controller. I recalled that some Duet users were using CNC router and CNC laser, so I did a quick search and found this. This post is a tad old and I'm wondering what progress you or other's have made. At the moment, I just upgraded my torch to a non-HF blowback model. Approx 4-5 years ago I tried the HF Arc Pilot torch with Mach3 and EMI was too much. So, giving this a go.. one more time.

[yngndrw]

@ddt154

I'm also wondering if there has been are work on this area, I couldn't see much in the forums about THC aside from another thread about an external controller.

Hypertherm provide some cut charts showing the sort of values expected for pierce height, pierce delay, nominal heights and feed rates. (Attached)
GDE_810050_R0_Duramax_Cut_Charts_Powermax45.pdf

In addition to their normal CNC interface (Divided arc voltage output, trigger input, arc transfer/okay output) they also have a second serial interface for additional information and control. (E.g: Mode, current set, actual current, type of nozzle) (Also attached)
GDE_810400_R2.pdf

I really like the Duet3D platform and would love to use it for my upcoming CNC plasma cutter build.

[o_lampe]

@yngndrw Thanks for the chart.
My approach would be to use macros for different materials. Maybe we have to post-process the cut file and add information about material and thickness (global variables)
For instance, a mild-steel macro would calculate the torch height and pierce times, etc.

Maybe we can use the filament folder for such settings?

[yngndrw]

@o_lampe My gut feeling was that, like in 3D printing, the material section would be the responsibility of the CAM (Slicer) but looking into it, it does typically appear to be the THC that has control over this.

Here's a screenshot from the Centroid THC profile manager:

It's interesting because as OwenD mentioned above, the feed rate depends on the cornering so in reality both the CAM and the THC need to know about the material.

If the THC does need this information, then I think you're right that the filament system is the appropriate place.

Hypertherm do provide timing diagrams for moving piercing on the much larger systems, so I've asked if they have the same diagrams for standard piercing on smaller machines:
https://www.hypertherm.com/Download?fileId=HYP113984&zip=False

[OwenD]

@yngndrw
Typically on higher end systems, the cut charts are a function of the nesting software.
In Hypertherm's case they extend the cut charts you've linked to and include different feed rates for holes and small profiles, but perhaps more importantly they disable the THC during these slower moves if the feed rate is such that the resulting reduction arc voltage would cause the THC to crash the torch into the plate.

Lower spec CNC systems that don't use cut charts typically have settings in the controller that might say

• Reduce speed to X% in corners
• Reduce speed to Y% for holes <Xmm
• turn off THC Xmm from end of cut

In lower spec systems, the THC is typically a separate unit and has its own settings for arc reference voltage, pierce delay, pierce height etc.

IMO, it is better to have the nesting software do all the "thinking", especially in a case like RRF where direct access to IO's etc is easy.
The "reprap" community will baulk at having to pay for commercial software and write their own post processor, but plasma cutting is not a trivial task and the various nesting software solutions have years of development in strategies for overcoming the various issues.
Whilst it's theoretically possible to have RRF do all these calculations , I have my doubts whether it could do all of it in real time.

This was a small unit I spent the last week commissioning
3.5m x 1.8m. 200 amps
Pierce capacity 32mm steel.

The large blue unit in the background is a fume extraction unit.
All the fumes from plasma cutting are carcinogenic.
Without fume extraction you'll fill your garage/shed with fumes in seconds.

[yngndrw]

@OwenD Thank you for this, it's always interesting to hear about how things are done on production systems.

I don't personally baulk at paying for software, as long as it's affordable. The issue is that sometimes the software is only priced for large industry players where there's no suitable pricing model for hobbyists. Do you have any suggestions for software at this sort of level? Sheetcam appears to be commonly used at our level, but I'm finding it difficult to work out exactly what its capabilities are as their website is rather light on detail.

On fume extraction, do you have any suggestions on what approach to go for - For a smaller, hobby-use system? The main approaches appear to be downdraft or a water table, but each appears to have serious downsides:

• Downdraft, how do you filter the air if you don't want to just dump it outside? I've not yet seen a filter design which wouldn't clog almost instantly.
• Water table, cleanup is a pain, as is the problem of stale water over time. Some people filter their water, but I'm not convinced about filter clogging for this either as the particulates appear to be extremely fine and there's very little in terms of information about the long-term performance of the various filter designs.

[OwenD]

@yngndrw

In regards to software...
All the systems I do use Hypertherm Pronest, but even the LT version is probably out of reach for "home" users.
I think a lot of people use FastCam on basic systems, but I haven't had first hand knowledge of it for about 25 years and even back then I was only running a router.
There are one or two open source projects but I have no experience with them.

Fume extraction is a major issue.
A down draft table is arguably the best method but a filtered system is very expensive.
You also have to have sufficient air flow.
On higher end systems, there are internal ducts and gates along the table which open in line with the cross rail position so that all your extraction is working on where the torch is.
Cheaper systems just have a tube entering one end of the table, however this means that you have to have a fan big enough to move the required air velocity across the entire bed area.
Typically they work "ok" while a full sheet covers the entire bed area and almost not at all if there are open spaces.

Water tables work quite well but have their own issues.
The water has to be treated to stop algae, rust etc and has to be changed (and disposed of) regularly.
Putting it down the storm water drain is likely illegal in most places.
Parts fall in and are hard to find.
It oxidises aluminium parts quickly.
If you are cutting aluminium there is a risk of a build up of hydrogen gas under the sheet as the fine aluminium dross reacts in the water.
All the O2 is stripped out leaving only hydrogen.
Whilst I've seen bubbling on many systems, I've only experienced one case of it igniting. That one made a huge bang and lifted a 20mm plate of aluminium off the table.