2026-10-20

Last modified: 2026-10-20 16:00:21

Plasma cutter

Today's experiment: does plasma-cutting near the CNC router stop the router from working?

The ground clamp and torch come off the "front" of the machine, whereas all of the stepper motor wiring goes off the "rear". The cutting process is I guess about 50cm away from the USB cable. The USB cable is longer than necessary, maybe 1m or 1.5m long, but coiled up at random, spanning an actual distance of maybe 15cm.

I set the router running a program that would just repeatedly move the X axis back and forth.

I made a few cuts in the bar, at both ends of the "water tray", and the X axis was still going back and forth so I thought everything was fine.

I then tried to stop the program from the laptop using UGS Platform, and nothing happened, it kept moving the X axis back and forth. I looked in dmesg and there was a "disconnected by hub (EMI?)" message and the Arduino reconnected and got a different device name.

So I guess the reason the X axis was still going is that Grbl was just running the commands that were still in its buffer.

So I do need to do something about EMI if I am going to control this plasma cutter with CNC.

Possible avenues, from easiest to hardest, include:

• move laptop etc. further away?
• shorter USB cable?
• shielded USB cable?
• reduce the size of the spark gap inside the plasma cutter case?
• try reconnecting to the microcontroller over USB every 5ms until it works and then continue streaming the program?
• communicate with the microcontroller over WiFi or Bluetooth?

I pulled the laptop and control box as far away as I could, measured the distance between the torch and the closest point on the USB cable at about 1.2m.

I set a program running and then just briefly pressed the trigger, to just light the pilot arc and immediately extinguish it, and the Arduino disconnected.

ChatGPT suggests running the laptop on battery power to see if the problem is caused by being plugged into the wall. Also leave the stepper drivers etc. unplugged from mains (so not actually physically moving the machine) and see if Arduino still resets.

Annoyingly, I can't reproduce it now. Lighting the arc, cutting metal, moving the laptop closer, even dragging the cable over so it is nearer to the torch, all is fine, no more disconnections.

Since this plasma cutter had barely been used, is it possible that the first few times you light it it generates more interference but after a while it settles in and all is fine? That would be a result.

I'm going to light the arc 50 times in a row and see if it triggers any disconnections.

OK, it's just intermittent. I did it maybe 100 times, and sometimes it would go 20 or more with no problem, sometimes 5 in a row would disconnect.

So let's try unplugging the laptop charger.

Still intermittently disconnects. With laptop charger unplugged and stepper drivers unplugged, i.e. no connection to mains ground from either the laptop or the stepper drivers, it still disconnects intermittently. So this means there is definitely disconnection caused by RF interference rather than conducted interference?

Apparently the cable I'm using is already "double-shielded".

I think our hypothesis is that despite being "double-shielded" and having ferrites on it, the USB cable itself is acting as an antenna and picking up interference. So we either need to make it less good at receiving inteference, or make the plasma cutter less good at transmitting it.

I think I read that someone did some measurements and determined that the greatest emitter of interference on their plasma cutter was the torch cable, so potentially shielding the torch cable would help?

Also, I do have a different Arduino with a short cable - I could plug that in to the laptop and see if that one disconnects every time I light the arc? If not, then that might suggest that the problem is actually to do with some of the other wiring connected to the Arduino inside the control case, or to do with the grounded control case itself picking up the interference?

And what if I twist the ground clamp lead around the torch cable?

The other Arduino sometimes disconnects as well. And twisting the ground clamp lead around the torch cable didn't help, here's how it was laid out:

So only a small free open loop between the torch and the ground clamp.

Oh, but since I'm mainly just lighting the pilot arc, the ground clamp is irrelevant. And the return path for the pilot arc already runs down the same cable sheath as the main current.

I can try disconnecting the torch cable but still leave the switch connected, hadn't thought of that. Unsure if that is safe to do, what happens to the electronics in the plasma cutter if the pilot arc is an open circuit?

With the torch cable disconnected I squeezed the trigger over 50 times and had no disconnections, so I think it is likely that the torch cable is responsible for emitting the interference.

What if we try wrapping shielding around the torch cable?

Still no good, still sometimes disconnects.

What about bonding the shield to the plasma cutter case?

Still no good, maybe better, hard to say. I verified that the shield has electrical continuity to a nearby earth pin.

But hang on, why is this disconnecting the Arduinos but not interfering with literally anything else?

A few ideas are:

• if I plug in some non-Arduino USB device does that sometimes disconnect?
• if I use a different laptop does it sometimes disconnect?

The USB stick stays connected continuously, only the Arduino disconnects.

Is the whole "hobby CNC machines are unusually susceptible to EMI" thing really just an Arduino problem?

I'll try a USB mouse, that has a good long cable instead of plugging straight into the port.

The mouse gets disconnected every single time even when the Arduino doesn't. So actually I think the shielding of the cable and enclosure are doing some amount of work to defend against the interference. And I also think that using an aggressively short cable might help? Given that the mouse gets disconnected by the interference and the USB stick doesn't?

Although the other Arduino with the shorter cable still suffered.

I can still try a different laptop.

And potentially the ESP32+FluidNC way where you communicate over WiFi is easier.

I have an Arduino Nano ESP32, can make a breakout board on stripboard that provides screw terminals for talking to stepper drivers and a relay for controlling the torch trigger, out of things I already have, so I feel like I can probably just do that and ignore the EMI problem for now.

Then have to decide whether I'm using old 3d-printer steppers (noisy, not very powerful, open loop) or Leadshine easy servos (quiet, powerful, closed loop). The only arguments against the Leadshine ones are that the closed-loop control is another avenue for EMI to mess things up, and I think one of the ones I have spare has had the connector cut off so I would need to deal with that. I don't necessarily need closed-loop control and I don't even necessarily care if a motor misses a few steps when the arc ignites, I can live with that if the physical distance error is small enough, it's plasma-cutting after all so not exactly high-precision, and likely each independent continuous loop would not suffer lost steps within itself anyway.

Before making anything I can put FluidNC on the Arduino Nano ESP32 and "pretend" to have it execute a program, streamed over WiFi, and see if lighting the plasma arc interferes with it in any way. If all looks good then build the breakout board and see if I can control motors, and assuming all is good there then build the actual machine.