Custom UI for FluidNC

Stoli · January 17, 2025, 9:12pm

I’m not sure if anyone has done this before, but I thought there might be a little interest. I can’t imagine those with a CNC Router or Mill wanting to do this (unless you absolutely loath the FluidNC WebUI and want a fully customized one). I think there are a lot of interesting possibilities for the Zen crowd though. My motivation was to create a friendly interface for a pen plotter I am working on.

Wall Mounted Pen Plotter

The downside… to make it work, you need a slightly modified version of the FluidNC Firmware. There are only 3 lines of new code that need to be inserted before the firmware is rebuilt, but I realize that this is an inconvenience for those who always want the latest version. However, if anyone is interested, I can upload a modified version of FluidNC Build 3.9.1, which is fairly recent. An upside is that your current FluidNC WebUI would not be affected. I can provide details of the modified firmware code if anyone cares. I can also upload the html and javascript files that make up the UI. They do not reside on the FluidNC board.

To make use out of it, a knowledge of HTML and Javascript is required. There are only a handful of files (html and JavaScript), and they can reside on your local device. A web server is not required, although I think to add value, the content should be dynamic and not static.

One example to consider … If you have a Zen and use Sandify a lot to create your g-code, it could be incorporated directly into the UI. Sandify is open source code and is written in JavaScript. That way, you could have a tablet running the UI next to the Sand Machine. Pick up the tablet, use Sandify to make something interesting, click a button and you’re plowing sand. Never left the couch. Food for thought.

Anyways, here are a few screen shots from my tablet. The first pic is just a tab with a simplified version of the FluidNC WebUI. Only the things I need to operate the plotter. The second and third pics show how I access art that has already been created and send it to the plotter. In the future, I hope to incorporate all the software that I use to create the art into the UI, so it’s one stop shopping – like the Sandify example.

Cheers!

jeyeager · January 17, 2025, 9:37pm

Now you’re speaking my language. I’m really curious about the code change. I’m wondering if this could be converted to a WebUI v3 extension so the code change is not required.

Stoli · January 17, 2025, 10:23pm

The code change deals with browser security. All web browsers enforce Cross Origin Resource Sharing (CORS).

Wiki - CORS

In a nutshell, a browser won’t run JavaScript that accesses resources on a server with a domain different than the domain that served the web page. So, in order for a webpage to upload and run files on the FluidNC SD Card (access its resources), the JavaScript in that page must originate from the FluidNC webserver UNLESS the FluidNC webserver grants specific permission to do so. That is what the changes in the FluidNC firmware do. They simply add a header to the responses of the custom UI’s requests (to access FluidNC resources) that tell the browser that it is OK to do so.

So, in the FluidNC firmware code, I add this line in three places:

sendHeader("Access-Control-Allow-Origin", "*");

and that tells the browser that it is OK to run the Javascript in the page (which is your custom UI) that originates from your local file system or server or anywhere other than the FluidNC server. It is not something you’d want to do if your FluidNC server is available to the public, but when is that the case?

Feel free to ask more questions. I’m not sure my explanation is very clear.

jeyeager · January 17, 2025, 10:47pm

Ah ok. I’m familiar with CORS. So, where are you running the UI from?

Edit: I forgot I did this experiment hosting a page on Azure and accessing FluidNC via a websocket. That doesn’t care about CORS. I never tried any HTTP requests where CORS would come into play.

Stoli · January 18, 2025, 12:10am

Your WebUI Shenanigans are very similar to my UI. As you know, you can use a web socket to send individual commands like homing and jogging and getting status reports back from FluidNC. My UI uses a web socket for most operations, just like your cnctest. And technically you could make a UI that sends the g-code line by line via the web socket, but that is, in my opinion, horribly inefficient and fraught with peril. I found that being able to upload and delete from the SD card was crucial, and that’s where CORS comes in because you can’t do that via the web socket. Thus… the firmware mod.

To answer your question, my UI is dished from a webserver available anywhere on the internet. The intent is to control a FluidNC device on a different network, anywhere with internet connectivity. I process and upload g-code and images to the server, make a few database entries, and the next time the user refreshes the web page (UI), that code is available for them to send to the FluidNC device on their local network. Obviously, a little niche scenario, but my point with this thread is you can do a similar thing locally on your own network and without a web server.

timonjkl · January 18, 2025, 1:28pm

To many smart people here wish i were one of them. I understand the concepts but not the nuts and bolts anymore. At one time but not now i can cut and paste so love the explanations with directions

jeffeb3 · January 18, 2025, 1:52pm

That is very cool. Sandify would need a separate exporter/downloader for sending the file to fluidnc instead of downloading it. A local copy would work fine for that. I wouldn’t want the global version to have this functionality (it just seems complicated from a user perspective). Sandify compiles down to just static files and could be served anywhere.

Do you have to disable the regular webui? I assume they are using the same websocket.

I would guess adding the CORS changes under a parameter would not offend the FluidNC team. Bart has a long history in plotting and would be pretty happy to be part of your work. You could make it slightly less insecure if you made the "*" be a specific parameter value. So users could use "*" or "drawify.org" in the config.

Can you just make this into a replacement for webui’s index.html.gz? Could the ESP host this? I think the big limits would just be the size, since the javascript all runs client side. It could be possible to use some resources via the Internet or LAN. Like a CDN. But that would not allow local AP only access.

The forum pulls in people from everywhere. Many of them are not here now and many of them will not post to ask. I would like to see it too. Can you post it to github or a similar git server? It doesn’t need to be user friendly unless we find some users.

jeyeager · January 18, 2025, 2:28pm

With the standard websocket port (81), it will let you have multiple connections, but bad things can happen like running out of memory. With the WebUI v3 port (82), making a new connection will disconnect the old connection which works well.

I would think that is possible but then you lose the configuration functionality. This is why I was questioning if this could be converted to a WebUI v3 extension. I haven’t seen to code but the answer is probably yes, if there is enough flash space. That would also allow it to all use the same websocket. However, from a user perspective, having to load the WebUI and then switch to the plotter UI is a little weird.

There’s also this FluidNC issue sitting out there to allow serving additional HTML pages. Right now, if you try to access an HTML page, it downloads it.

github.com/bdring/FluidNC

Feature: Allow any .htm(l)(.gz) to be viewed as webpage

opened 01:47PM - 22 Feb 24 UTC

woutervddn

enhancement

### Machine Context I'm automating my tablesaw, basically it has 3 motors: fe…nce, angle and sawblade height. The interesting thing here is that the useful blade height is dependent on the angle. So for this machine, the interface that makes most sense is one that only shows the relevant input parameters for the user and calculates the correct motor positions from there. I made an example interface in 20 minutes that can also automatically subtract blade width or any other form of math in the input field. Or if you enter an angle that is below 44° that it knows that you actually want the compound angle (since the blade only goes from 92° to 44°) I've got a video of the (demo) interface in question: https://github.com/bdring/FluidNC/assets/1514131/44ad78ed-588f-418d-88a2-569acd190f18 ### Feature Description Allowing for multiple html pages to be viewed greatly reduces the barrier for machines to have specific interfaces. Only the needed buttons or elements would be available and the rest would be hidden. Currently the tablet page is in a separate tab but making changes to that interface requires you to download the upstream project, understand the entire UI system, make the changes, compile and upload. Which is way harder than just having to create a webpage with basic fetch calls to the command interface. The separate interface I built is (granted without the fetch calls being implemented) is 3.1KB The functionality for this is also already there (in a way) as you can upload a custom 404 page which is my current workaround. ### Other Approaches A custom interface could be added to a tab in the existing index page. But that requires you to understand it all and compile for each change. Another approach would be to just make your interface and upload that as index.html.gz. This would result in the user needing to recreate all (or a lot) of the index.html.gz functionality (like file upload etc) which seems unrealistic. Or go without that functionality, but even replacing the index.html.gz back to the old version for a configuration change or maintenance would require more hoops to jump through. Having a separate UI for 'daily use' and the default index.html.gz for configuration+maintenance just makes more sense in that way. ### How I Can Help The change is small and I'm pretty sure that I can make it on my own, no experience writing tests though... Help in that regard and a second pair of eyes to verify what I wrote would be appreciated.

There’s other quirks around serving pages too. Like the websocket is over HTTP so you can’t access it from HTTPS. Some of this could get interesting if you want to call other APIs (like I see the Spotify tab).

Stoli · January 18, 2025, 3:15pm

What Jason said.

Mitch Bradley was very helpful regarding the CORS change. As a matter of fact, he opened a branch on Github called CORS to help me zone in on where the changes needed to be made.

I didn’t try replacing the index.html.gz. Thought about it, but for my project it wasn’t going to get me where I wanted to go. Also, I liked the idea of keeping the FluidNC WebUI in tact. I use port 81 for the web socket and haven’t had any problems. The server just opens another socket. There are a few quirks, but nothing major.

I’ll scrub out all the extraneous stuff in my UI and upload the files when I get a chance. There isn’t that much to it.

Mixing http and https is getting increasingly more difficult , especially if the content is coming from both public and private networks. Browsers have been slowly plugging up those security holes for the past few years. They used to give you a warning, now they simply don’t display the content and it is up to you to look at the console in the developer tools to see what is going on. Most DESKTOP browsers allow you to dig into the settings to make it work. For instance there is a setting called block-insecure-private-network-requests (may be slightly different name browser to browser) that can be disabled. It’s an ugly solution in my opinion, but I don’t see FluidNC going to secure sockets any time soon so it is something that would have to be dealt with - a proxy comes to mind, but again, not an ideal solution. To complicate things even more, I have found that mobile browser don’t allow the user to disable the setting I mentioned above. At least I couldn’t figure out how to do it on a tablet or a phone.

For now, my UI works well on Firefox on a tablet. Chrome is off the rails these days. Safari is Apple, so they don’t allow users to make decisions for themselves, never have. Edge is somewhere in the middle.

Stoli · January 18, 2025, 3:22pm

Forgot to mention the Brave browser. I find that to be similar to Chrome except if you use Chrome, the Google people know when you fart in your living room. If you use Brave, I don’t think they know. Maybe someone else does?

jeffeb3 · January 18, 2025, 4:29pm

I usually install firefox and chromium, which is the open source version of chrome.

On mobile, the duckduckgo browser is good. It sort of defaults to private browsing, unless you “fireproof” a site to stay logged in.

Stoli · January 18, 2025, 5:51pm

Here is the code.

UI code:
control.zip (15.1 KB)

Modified FluidNC Firmware:
fluidNC_3.9.1_CORS_mod.zip (1.1 MB)

Edit: I updated the firmware file in the above zip. Previous file was an earlier version of FluidNC.

If you want to try out the code:

Set your FluidNC IP address in settings.js
The Pick a Plot, Spotify and Text tabs all need to reach out to my server to work, so there isn’t any functionality there. You should be able to send commands via the Web Socket section, but the SD card interaction would need the modified firmware to work. The “Pen” buttons run macros on fluid, so obviously they won’t do anything, but I included those macros in a folder just for reference.
When control.html is loaded, there is a line of js at the bottom of the page that opens the web socket: connect(objDiv); That function is in the websocket.js file. All the other code is in the control.js file.
If your FluidNC is up and the ip address is correct, the status light in the Web Socket section turns green and off you go.

Stoli · January 19, 2025, 6:45pm

Hey guys, I just realized that the modified firmware file that I included in the link above was a slightly earlier version than 3.9.1. It shouldn’t impact testing or anything if you already uploaded it, but I updated the previous post so it includes 3.9.1 now. Sorry about that.

jeyeager · January 19, 2025, 7:20pm

The changes are just these two instances of adding the Access-Control-Allow-Origin header, right?

 _webserver->sendHeader("Access-Control-Allow-Origin", "*");

WebClient.cpp → WebClient::write
WebServer.cpp → Web_Server::sendJSON

Comparing main…CORS · bdring/FluidNC

Stoli · January 19, 2025, 8:01pm

Yes. I also added it to

WebServer.cpp → Web_Server::_handle_web_command

Which I am not sure is necessary, but it’s not hurting anything.

Stoli · July 7, 2025, 4:56pm

I took this to the next level the other day and thought I’d share. I have wanted to figure out how to create my own IOT cloud for a while now, so this was a good reason to head down that rabbit hole…

Objective: Remotely control FluidNC from my phone from anywhere.
Constraints: No router mods, static IPs or Port Forwarding, etc.

Total cost in parts and services: $6.49

Participants involved:

V1E Jackpot running FluidNC w/Local IP Reservation (OK - small router mod here)
ESP32-CAM ($6.49 on Amazon last I checked). The ESP32 has a built in camera and SD Card slot. It requires 5vdc. This gets loaded with a sketch called CameraWebServer via the Arduino IDE. I then added two websocket clients to the sketch, one that connects to FluidNC (i.e. ws://192.168.x.x:81) and the other to a tunnel that is set up on CloudFlare (ws://wsserver.mydomain.com)
CloudFlare Account (Free) Set up a tunnel as a subdomain (i.e. wsserver) of your main domain (mydomain.com). The tunnel is configured as an http service on the port that the nodejs websocket server is listening on.
Nodejs and cloudflared running on a box somewhere. I used a linux server on my home network, but all you need is a pi (or equivalent). I haven’t used it in a while, but Amazon AWS might provide a free instance that you could run this on if you want to avoid using your home network.
Control page (html & javascript) running in a browser. This can be a local file if on a PC. Must be dished from a webserver if using a phone or tablet. You could also program your own Android or IOS app.

Overview:

Summary:
The ESP32-CAM sits on the same LAN as FluidNC. All traffic coming from the FluidNC socket is redirected to the Cloudflare socket. Traffic from the Cloudflare socket is forwarded to FluidNC with the exception of image requests. If an image request is received, a current snapshot is taken from the built in camera and sent back to Cloudflare as a binary file. The websocket configuration isn’t suitable to handle streaming video, but it should be able to handle a snapshot every 0.5 seconds or so. I also set up the ESP32-CAM to send an info request (?) to FluidNC every 10 seconds.

The nodejs websocket server (nodejs ws) is configured to forward traffic to all clients except the one it received the traffic from.

Finally, the control.html file sets up a web socket connection to ws://wsserver.mydomain.com using javascript and sends and receives data just as it would if FluidNC were on the local network.

This is basically how any smart device (outlet, switch, cam) that you buy on Amazon works, except here we use our own cloud, so it is more secure and private, and it is configurable to do anything you want, not just what the manufacturer’s app is programmed to do.

Here is a screenshot from my control.html page.

There is a pull down with all the commands I use (home, move to preset positions, select and replace pens, advance the paper, lights on/off, reboot, clear alarm …). I can also run gcode files that are on the Jackpot’s SD card. Feedback is provided via the FluidNC status messages as well as snapshots from the camera. I have not programmed the ability to upload files to FluidNC since this can not be done via the web socket, but there is an HTTP Client library for the ESP32, so I think this can be done by first transferring the file to the SD card on the ESP32-CAM via web socket, then have the HTTP Client on the ESP32-CAM upload the file to FluidNC using http. So, I can pretty much do anything except load pens.

Secure sockets (WSS) - Last I checked, FluidNC is not programmed to use secure web sockets, so the socket on the ESP32-CAM that talks to FluidNC would need to use WS, but I don’t see any reason why the rest of the traffic can’t be set up as WSS. I believe you would just need to create a certificate and upload it to the necessary players.

jeffeb3 · July 7, 2025, 5:14pm

Have you looked at cloudflare? If you have a registered domain, you can set it up on cloudflare and run a small service locally to tunnel out to cloudflare. They handle the security and you can choose several ways to log in and it will be like it is on your lan without VPN.

Stoli · July 7, 2025, 5:28pm

Yeah, that’s what I’m using here. Unless you are referring to something else? Maybe I wouldn’t need my own certificate now that you mention it. Haven’t tried wss yet. I have a bunch of tunnels set up to different devices on my lan (web server, 3d printers, etc.) and cloudflare makes it real easy to secure all those.

Tokoloshe · July 7, 2025, 5:44pm

This is incredibly cool. Thanks for sharing.

jeffeb3 · July 7, 2025, 5:52pm

I set cloudflare up on my home assistant server. It is very much at the border of my understanding. I know O run a cloudflare service in a docker container on my lan to set up the socket. I did not spin my own certs. The communication on my lan is not encrypted.