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.
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.
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.
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.
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.
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.
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
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.
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.
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).
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.
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?
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.
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.
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 