2026-10-22

Last modified: 2026-10-22 13:23:00

FluidNC plasma cutter

I took my temporary assemblage of power supply, breakout board, stepper driver on breadboard, and stepper motor out to the garage, set it running demo.nc, and started the plasma cutter near it maybe 50 times.

The stepper motor kept following the program without any apparent interruption.

However when I finished and tried to look at the web interface again on my phone it said I had been disconnected. OK, I had switched off the phone and put it in my pocket, so that's not necessarily strange.

Then when I clicked reconnect it didn't work and reloading the page got "Connection failed! Is your FW correct?"

What's an FW? A firmware? Strange error message.

I couldn't get the phone to reconnect to the page, but the program was still running.

I then reset the ESP32 and was able to connect to the page again.

Oh! ChatGPT points out https://forum.v1e.com/t/connection-failed-is-your-fw-correct/51413

FluidNC apparently deliberately blocks downloading the web UI during running gcode because it can interrupt the motion control. So potentially everything working as intended here, that's good.

But I do still need a way to be able to control it while it is running motion. I guess next try is connect the laptop to the WiFi and use a g-code sender that works over WiFi without using the web UI.

Apparently UGS supports FluidNC over WiFi.

But that will be streaming g-code over WiFi. We may want a custom sender that can send a gcode file to the LocalFS so that WiFi interruptions don't interrupt motion control. Or maybe streaming over WiFi is good enough, let's at least try it.

To use UGS over WiFi I apparently need to set:

• Connection driver: TCP
• Firmware: FluidNC
• Host: 192.168.0.1
• Port: 23

I probably need to update UGS to make this work, and also I don't want it to overwrite my CNC router UGS config, need to make sure UGS can keep track of both.

Another option is to vibe-code a minimum viable g-code sender for my purposes, and that would also make it easy to upload the g-code file to the LocalFS. May end up easier than mucking about getting 2 independent versions of UGS installed, and has superior resistance against WiFi interruption.

I guess let's set Codex on this now and see how it gets on.

I wrote a SPEC.md and set it going, it worked for 45 mins and thinks it is done, need to give this a go after lunch. This was with gpt-6.1-sol high.

OK, sick! This fucking works. Unbelievable. This thing has one-shotted a working gcode sender in 45 minutes and hit every feature I asked for.

I just ran it on the laptop, sent a gcode file and repeatedly struck the plasma arc, probably 50 times, the program kept running the whole time, and I was still able to pause and resume etc.

Also, now running on the breakout board instead of with the USB power adapter, that random LED on the Arduino board no longer lights up every time I squeeze the trigger, so that has to be an improvement.

Naturally I have some changes in mind so I will have a 2nd iteration, but this is already workable as is.

Changes are:

• it has made up its own local file browser instead of using the system one, and it sucks; is this an egui limitation?
• some gcode files give an error about "K words not supported" or something, I think where it is trying to use a Grbl drilling cycle, maybe just can't use that cycle on FluidNC; in any event I won't be running a drilling cycle on a plasma cutter but we may as well support it if it's just a limitation in the GUI
• The window toolbar entry has no icon
• Controller enters the ALARM state after I stop the job
• "ALARM:3" stays in the status bar at the bottom even after I unlock the alarm and get back to IDLE state
• The "Log" view seems to be a combination of a FluidNC console view and an application internal log, these should be 2 separate things, and I know I didn't put this in the original spec but I would like to be able to type things into the FluidNC console
• Feed override and DRO display seem very slow to react after values are changed, is this due to the status polling rate being too low? should we either increase that rate or at least do a special one-off poll after we know we've sent changes? or something else is going on?
• rapid moves are displayed in a more prominent colour than feed moves, should swap these
• the processed/uploaded version of the gcode shouldn't have more than 3dp on positional values, and doesn't need leading zeroes on G codes except G0
• add a feature that will make the machine physically trace around the convex hull of the job, like UGS Platform has, at current jog speed, as a sanity check that it isn't going to hit any axis limits before sending it for real

It's had to do one context compaction, and I've noticed context compaction takes a really long time these days, nearly 3 minutes, probably doing something clever to make sure the most important information stays in there, rather than just chucking away the first half or something.

It spent another 35 mins working on the 2nd iteration, definitely diminishing returns here.

Good enough now though, I'm satisfied with this and will stop messing with it. A bit over 5000 lines of code.

https://github.com/jes/plasma-wifi

So next step is either to make the real electrical cabinet, or else the real motion platform. Or perhaps experiment with Leadshine motors. I think I would rather use the Leadshine ones if they are going to work because they are more powerful, so probably that's the next thing to check.