I’m not sure what reason I have to do this, but sometimes you get an idea and you just have to scratch the itch. If you have the V1 8MB ESP32, and you’ve installed FluidNC to take advantage of that space, you can have both WebUI v2 and WebUI v3 on the ESP32 at the same time. You can then use macros to switch back and forth.
I haven’t used v2 in a long time, so don’t worry about the config file error. I just don’t have homing amps set.
The only files that need to change between v2 and v3 are index.html.gz and preferences.json. So, with v3 active, I have the v2 files stored as index.html.gz.v2 and preferences.json.v2. So, when you click the macro, it renames the current files to add .v3 and removed the .v2 from the V2 files. The V2 macro does similar.
V3 Macro - These lines are joined together separated by a semi-colon.
Now that I think about it, instead of switching between v2 and v3, this concept would be useful for testing WebUI v3 releases. So, I could switch back and forth between a known good and a new version.
I forgot about my other experiment. FluidNC supports WebSocket connections. I’m not sure you can do everything through that type of connection, but you can do quite a bit. Check this out:
Note that you can’t use “https” because you can’t connect to a non-secure websocket over a secure connection. Don’t worry, this websocket connection is happening on your local network. Access to your CNC is not happening over the internet. It is just serving the web page.
This is 100% external of the WebUI. It relies on the FluidNC functionality used by the WebUI. I connect using the WebSocket URL ws://192.168.0.240:81
192.168.0.240 is the IP of my machine and 81 is the websocket port. If you are set to the default fluidnc.local address, then ws://fluidnc.local:81 also works.
I can jog, see the position update in real time, send commands like $SS. This is just an experiment that I found interesting. Not sure how far I would go with this but it’s an interesting idea. Using a variation of my UI switching method earlier in this topic, you could switch between this and WebUI. You could host it somewhere inside your network, or on a Raspberry Pi or anything with an HTTP server. You could probably rig up a separate ESP32.
Some more playing with Websockets. Took another ESP32 and had it connect to the ESP32 on the Jackpot via the websocket. So, when it starts, it connects to the same network as the other one, connects to FluidNC via websocket, and sends jog commands back and forth in X by 10mm. Now if I can just take the left over joystick from the spacemouse project, and the logic from my joystick extension… I’m sure that’s possible by a direct connection to the Jackpot, but I’d want to mount such a thing on the table and not have to deal with a cable. No idea what will come of all this, but fun to play with.
Lol I don’t even know if this is going to work out and no where near ready for that level of sharing. Right now, this is mainly for my learning and entertainment. Still just shenanigans.
The big thing is the WebUI uses a websocket as well and I haven’t yet determined if I can have both going at the same time or how to cleanly switch between the two.
If this all worked out and I had the ambition to go that far, the end game would be a panel I can mount on my table with a joystick, screen, and buttons that basically combines my joystick and hold monitor extensions. So, jog, home, see last message, and resume, plus maybe some buttons for other things.
This is completely unnecessary but fun to mess with. I could you know just mount a tablet or pull my phone out of my pocket.
There’s still something that feels good about having a physical joystick and buttons. I had a loaner car a few weeks ago while my car was getting fixed. It had a touchscreen for everything and I missed some of the physical controls.
With the caveat that this may not be this way forever…
Currently, there are actually 2 Websocket ports open.
by default, those are 81 and 82.
This was necessary because of the way that the protocol between the 2 web versions had overlapping functionality that caused programmatic confusion on the backend.
I’m working off the top of my head here, but will check a bit closer later, so take this with a grain of salt…
I think the WebUI-3 port (82) assumes only one connection will ever exist, so when you connect with a second websocket, it will kick the previously active one off.
The WebUI will handle it though, and you will get a screen saying you logged in from another spot, with a button to reconnect.
However, if your board implements reconnects, you’ll likely be fighting each other.
It may be possible to have your board use the WebUI-2 port (81) and not conflict, as long it doesn’t cause resource problems on the FluidNC side having both being served simultaneously.
With the refusal of the FluidNC changes being accepted as part of the official repo, I suspect the multi-port thing won’t stick around forever though.
Are you using actual jog commands or G1/G0? It looks like it overshot a little. I remember seeing jog commands at some point and the benefit there is that they don’t have to reach their destination if another command interrupts them.
The alternative is to send smaller commands faster. But you risk stopping due to lag.
This is connected to FluidNC via a websocket connection. It’s getting status, position, and messages via that. I had a version sending jog commands using the joystick that way too but am currently restructuring that code.
I’m intentionally going the wireless approach because I like the idea of having something mounted at the front of my table without having to worry about running that wire. That display supports touch but there’s just something that feels nice about physical controls. Otherwise, I’d just use the WebUI.
Not only will it work wirelessley, you could have a wireless AP/Router local to the machine and cable the pendant over copper, while the FluidNC host (Jackpot) connects tot that local AP wirelessly.
There are many interesting options for this interface.
Thank you for that. This is very similar to what I’m trying to achieve. A lot of this is a learning experience. The project it’s based on is even using a milled PCB which would be fun to try.
My primary goal here is learning. My secondary goal is to achieve the functionality of my Joystick Jog and Hold Monitor WebUI v3 extensions. So, options to jog in XY, X, Y, and Z just with a physical instead of virtual joystick along with homing. Be able to see the last message displayed so when a hold happens, I can take the appropriate action (such as attach/remove probe) and click a button to resume. My intention is for this to supplement but not replace using the WebUI.
