Advice on adding plasma torch height control

[dc42]

A few questions:

• How do you set the gap initially, before you apply power to create the arc?
• What type of motor or other device so you use to adjust the height: a stepper motor, or something else?

I know nothing about plasma torches, but if you use the Z stepper motor to adjust the height then my thoughts are:

• Define a new GCode (M454?) to switch the firmware into plasma torch mode. Allocate it in the wiki at reprap.org. Also check that Marlin doesn't already use that code for something else - the Marlin devs tend to ignore what everyone else is doing and not document what they do at reprap.org.
• In plasma mode, redefine M3 as plasma on/off or plasma strength (unless you think another code would be more appropriate).
• When M3 is used to turn the plasma on, activate the PID that controls the Z motor from the plasma voltage. When M3 is used to turn the plasma off, deactivate it and update the user coordinates from the machine coordinates.
• Put the PID and other plasma control stuff in a new class. Copy the PID code from the one used to control heating. It's probably not worth trying to share the code because the one used for heating is customised to that application.

HTH David

[mawildoer]

Thanks @dc42 , that's the workflow I expected. I'll double check the M454 with Marlin

Regarding the gap, it depends slightly on the type of torch, but for mine and other cheap torches:

1. The torch begins at z top (for arguments sake ~30mm above the work piece and the Z axis is low-load so high speed)
2. M3 is called to start the torch
3. The plasma is turned on. Vref will immediately go to max, ~90v (which will be read through a voltage divider, low pass filter and probably some other protection)
4. The torch lowers via the PID until the an arc at is established at the desired voltage (which will be set in M3 using the S(?) parameter)
5. Once the voltage is deemed stable etc... M3 continues, allowing the program to run normally
6. A dwell should be included after the M3 to allow for piercing of the work-piece, but this can/should IMO be a standard dwell for the sake of tuning for different materials

My apologies, I wasn't very clear by 'preference on how I can add this functionality', but I meant how you would prefer/recommend the functionality to be implemented. After having a look through the code (well commented I must say!) this is my current plan:

• Add 'plasma' to Enum MachineType (https://github.com/dc42/RepRapFirmware/blob/dev/src/GCodes/GCodes.h)
• Add configuration basically the same as laser and cnc are handeled
• Add M3 Sxx command for plasma MachineType. I'm currently expecting this to add the waiting functionality using a GCodeResult::notFinished similar to these !!!(https://github.com/dc42/RepRapFirmware/blob/dev/src/GCodes/GCodes2.cpp#L3330)

The other thing I'm having a little trouble with understanding is adding the motor control for the Z height. You've already obviously got a reasonable step generator which I'd ideally reuse. Can you recommend the best place to tap into it to? Do I need to schedule a new task in the RTOS?

Thanks once again

Matt

[dc42]

That all sounds good. For the Z height control, the difficulty is that currently the step generator assumes that all motors move synchronously to execute the same move. When the plasma torch is executing a long straight move then this won't be the case. I can think of a few ways to solve this:

1. Don't use the existing step generator to adjust the height when the plasma torch is operating. Instead, use a separate RTOS task to generate individual steps. This would be quite a simple option if the maximum step rate needed when adjusting the height is low, e.g. 100 microsteps/second or less.

2. Add an interface to the existing step generator so that the Z steps can be changed live during a move. You would pass the step interval and number of steps. This would update the Z DriveMovement object and re-insert it into the correct place in the DriveMovement list. You would need to have the DDA Init method allocate a Z DriveMovement object even when the input move doesn't include Z movement. When one move DDA completes and another starts, any outstanding Z movement would have to be copied over to the DM for the new move.

3. Use a separate DriveMovement object (not attached directly to any DDA) to handle torch height adjustment. When starting a new move, always link that one into the DM list. As in #2, have an interface that allows the values in that DM to be changed and the DM to be repositioned in the list.

I think I favour #3. The PID could either be a separate RTOS task, or hooked into the Heat task if 0.5sec sample interval is fast enough.

I will be making substantial changes to the DDA/DM system in the near future in order to implement S-curve acceleration, and I will bear your requirement in mind. Someone else had a requirement for doing stepper motor movements that were not synchronised to regular moves, so this has more general applicability.

[mawildoer]

Great, thankyou. I'll take a look in the whole back end of things!

Can you point to anywhere beyond the code for any documentation/diagrams etc... that may be of use?

[dc42]

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

Great, thankyou. I'll take a look in the whole back end of things!

Can you point to anywhere beyond the code for any documentation/diagrams etc... that may be of use?

Only the readme file that gives an overview of the coding standard used, and the FreeRTOS documentation if you need to do RTOSy things. Most of the RTOS functions that RRF uses have C++ interfaces in the RRFLibraries project, so use those in preference to calling FreeRTOS directly.

[mhackney]

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

[dc42]

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

That's a good idea! 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.

[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