Indeed, the butterfly effect can be crazy in low level integration coding
That’s why part of me still think hosting the webUI on an rpi could be “the right path”
Controlling the machine, executing the gcode has to be low level and stable, the WebUI has to move quickly, hence maybe they have to live on different architectures
The thing is, once I have an rpi in there for the WebUI, why not just use klipper after all…
Ah… cruel world!
Once again, DWC has an interesting take on this, you get to choose if the ui is executed on the board itself or on an attached SBC, it’s up to you, and you board compatibility (eg: an arduino/ramps would never run the UI, but you can still add an rpi for this, whereas if you have a 32bits board with enough memory and wifi, you can run the UI on it directly)
Reminds me if the saying: “If builders made houses the way programmers write code, the first woodpecker to come along would destroy civilization as we know it.”
I did a bit more looking into DWC, and the structure is intriguing. The new Duet 3 boards can offload a bunch of stuff to a SBC, so that is getting less and less dependent. The Mellow Fly board that runs it on an ESP32 is cheap, and seems quite robust. Of course I have no idea what changes would be requited to make it work with Fluid vs. RRF, but the primary communication seems to be RS232 serial to the mainboard, so as long as you have a UART, it shpuld be possible to make something like thst work.
The ESP01S modules with the 8266 chips are REALLY cheap, and the interface there wasn’t bad at all. The only real complaint I had was when it forced 8.3 filenames, which was primarily a Marlin restriction then, and I think got solved (I swapped to the Duet though, so the ESP01S module still has the old software on it. This was before V1 firmware was adapted on the SKR Pro to put the module on the mainboard, so mine was on the TFT35 board.)
I’m impressed by the ESP. Agree, there is a lot of room to exploit and optimize. Remember that a lot of the things we want are UX, where the compute is in the browser. The ESP doesn’t have to do more work, it just delivers a bigger payload.
Yeah, I’m gonna wait and see how V3 develops. Right now I have a decent workflow. I just want some UX improvements. For example, an easy way to perform an “aircut” without losing my Z, and/or mucking about with fat-fingered Gcode to manage coordinate systems, or reminding myself to write some better macros next time, which I will never do. Yeah, yeah, it’s not that hard, but there are a million things to forget you didn’t do, or do out of sequence, or type wrong that result in real-world disaster.
Some thoughtful UI could mitigate a lot of that and make the out-of-box experience way more better for everyone.
I suspect the folks on this forum could contribute a great deal.
Just to confirm: the above content is from preferences.json, not macrocfg.json?
What is macrocfg.json ? Is it perhaps a v2 thing, while putting the macros in preferences.json is a v3 thing?
Based your mention of “preferences file” I happened to mention “preferences.json” on the dev Discord, and Mitch commented indicating he thought it was in macrocfg.json
WebUI3’s JSON apparently has an extra CMD value for the “target” field in addition to SD and ESP (which WU3 names FS or some such)
So does this mean WebUI v3 can do text files for the macros… “or” commands in the action box? I think I prefer the text files way of doing it from v2, in general.
The difference between V2 and V3 as far as preferences.json vs individual files, is just the way that the UI has decided to store it’s own settings so it knows where to put buttons, and what to do when you click them
Once it becomes a button, the text that you saved gets sent over. There should be no functional difference between the 2, unless there are bugs in the V2 or V3 UI or something.
I didn’t go read the conversation, but I will presume what Mitch is talking about is a different format of the web request that is generated when the V3 UI button is clicked.
This is what the bulk of the work I did to support V3 was about, differences in protocol.
Having the commands stored in different files or in a single file shouldn’t affect anything, but the V3 method of defining and editing those Macros, in my opinion, is much, much better
I’d love to see one of the many browser-based code editors with a gcode profile for syntax highlighting, whereever we are typing gcode. I use vscode with the gcode profile a lot.
There’s so much good stuff out there these days. Looking forward to seeing v3. I spent last night fixing my Hubitat, but one of these days soon I plan to have a look at it. Maybe after taxes
so if the TFT from the skr board has its own firmware, would it be possible to create a user interface using serial data or something similar to the pendant while using minimal processing time from the esp32?
Just throwing this out there - if you are JavaScript savvy, you can create your own local UI on top of the webUI that FluidNC dishes out. Best of both worlds as they say. I’m sure most users wouldn’t benefit much from doing that, but it isn’t all that complicated if you know your way around js. My motivation was to dumb down the FluidNC WebUI to something a bit simpler and custom for my own needs. If I want all the original features, I can always load the FluidNC webUI. The one caveat is if they are both open in a browser at the same time, some problems arise, probably because of the websockets. And the one hurdle I encountered was a cross-origin issue dealing with file uploading. I could be missing something, but my understanding is that everything in FluidNC can be controlled through the websocket except file uploading, which is done via a POST request. The websocket doesn’t care about cross origin requests, but the file upload URL (page) does. To clear that hurdle, Mitch created a branch on github called CORS, which simply modifies the headers on the page that accepts file upload requests.
Anyways… just a possibility for someone who wants to customize some things without forking the firmware.
Mmmmh okay… I just tried the new v3 UI and… erm… let’s just say it’s not quite ready just yet…
If you have a spare board and want to check it out of curiosity, why not, but maybe do not update on your mpcnc board
I’m a bit concerned about where the UI is headed right now…
Using preact and other JS libraries looks like a good idea, the plugin susyem has a lot of potential, but the interface is… how can I say that without hurting anyone? it’s a mess… and it’s ugly
It’s only alpha right now, so a lot of things can change, but still…
“Cherry on the cake” (as we say here…), switching back to WebUI2 fails and you have to physically connect to the board to issue a comand for deleting a file…
Not the best experience I must say… I’ll stick to the v2 I think…
EDIT: Trying to be a bit more constructive here, the widget things is IMHO a good idea in theory, but really a terrible waste of space and a very confusing presentation… even more so when those widgets can’t be resized or moved freely. I know that’s a lot of work, and it’s not an easy feat, but the way I look at it, v3 will be a lot less tidy, and a lot less usable on small screens I hope it’s just the alpha state that is causing this, but I fear there’s something a bit more deep to it
I am not really following that. To me V3 is clearly better in every way and seems to be perfectly production ready (there are always things that can change), and is much more robust in terms of connections. (try connecting a second device).
I feel it is a huge step up from V2.
Maybe something went wrong on your install, or maybe the latest fluid update broke something. We have been using v3 for months behind the scenes.
To switch you need the index file and your preferences and settings. As far as I know you should be able to swap them in, and delete or rename the others.
Yes I read this on the release notes
I need to bring down the laptop and connect it through USB tough, as the web ui won’t start
Nothing we can’t fix but it’s yet another small hurdle
I stated this mainly as a warning for anyone willing to test out the new ui, it’s not quite ready for real use yet, and switching back is not totally transparent, just a word of caution…
