I don;t think V3 is ready yet for the masses. It is very close. That is why V2 is still currently the suggested route.
When the LR4 is out and the dust settles, the jackpot and docs is next on the todo list. Things like not running wires over the antenna and how to use V3.
Can we connect and flash a USB wire connected ESP32, while it’s mounted to a 24v powered Jackpot board? Or, must the ESP32 be removed before flashing or connecting USB wire?
Would like to make fast edits/updates for fully wired (and powered) test rig.
That is the troubleshooting section. To flash, USB only, do not power up the 24v use the web tool. It was updated yesterday and is working a bit better again.
Unclear whether ESP32 needs to be removed from Jackpot during flashing.
Was unclear whether Jackpot main 24V power needs to be powered off. But you clarified a few mins ago.
I’m ASSuming ESP32 can remain mounted to Jackpot during USB flashing, but Jackpot 24V supply should be deenergized/powered off? Guessing ok to remain plugged in while powered off to remain grounded.
After some investigation, the persistent extensions does mean that they stay loaded. Before, if you switched between the dashboard, then the settings page or a page extension and back to the dashboard it would reload. Similarly, if you had a page extension and switched away and back it would reload. This is helpful depending on the extension. It also means that it’s loading all extensions on page load instead of just panel extensions. So, for something like my hold monitor, if you don’t want it taking up space on the dashboard, you could just make it a page extension and the hold popups would still occur. Otherwise, that would only work if that page extension was active. That’s useful.
I’m a bit annoyed at the moment that as part of this, it’s doing some weird things for how it’s setting size and position of panel (dashboard) extensions. It also adds a 10px padding to the content of an panel extension that you can only override in a theme. So, basically, I have to size things to deal with that extra space so it looks reasonable in my themes and in the base theme. It also means that a feature of my theme where it would allow dashboard panels to shrink if they didn’t need the full size (like Status, Terminal, Macros) is now no longer possible.
I’ll get my extensions and themes updated within the next few days.
There is another new feature that allows you to specify the default filesystem for the Files panel. So, now instead of defaulting to Flash, it defaults to SD which makes more sense. However, there’s also an optional “Sort files” option for Flash and SD. It seems to sort properly for Flash, but not SD.
The flash vs SD stuff I thought was already there in the previous version.
One thing to keep in mind is that the WebUI 3 is still considered Alpha stage, so there are bound to be issues.
Luc has been pretty responsive to issues in the past, so if there are things you think might be bad behavior, I usually report it in the ESP3D discord and he takes care of them pretty quick.
Given the scope and memory use of extensions, it seems like persistence might be something you’d want to have each one opt in to, especially with message processing, etc…
Maybe but I don’t remember the SD sorting being messed up.
Once I poke it a bit more, maybe I’ll reach out on Discord.
I’m not sure. A lot of the message processing is common where the same thing is shared with all extensions. So, the number of requests probably scales fine. I agree that maybe if you have multiple larger extensions, perhaps it could become an issue.
I’m thinking more along the lines of conflicting message processing more so than scale.
Like random popups not related to your currently loaded page, etc.
Memory/performance wise, I could see it being a problem dealing with things like the tablet extension and the gcode viewer etc.
Keeping extensions in memory and fully functional when you aren’t using them seems a bit dangerous to me, but maybe it’s not as big of an issue as I picture in my head. Will need to see how it shakes out maybe…
This is a WebUI issue with the FluidNC specific code. Although, it looks like it duplicates the GRBL code which I assume is also wrong.
It has to do with having a config setting named “sort_sd_files” vs “sort_directsd_files”. So, it can be fixed by either updating src\targets\CNC\FluidNC\DIRECTSD-source.js or src\targets\CNC\FluidNC\preferences.json so they use the same config value. I’m not sure which is more appropriate but changing either fixes the problem.
DIRECTSD-source.js
formatResult: (resultTxT) => {
const res = JSON.parse(resultTxT);
if (useUiContextFn.getValue("sort_directsd_files")){
res.files = sortedFilesList(res.files)
}
res.status = formatStatus(res.status);
return res;
},
Yes, the general recommendation from the FluidNC guys, is not to use AP mode long-term. See here.
This recommendation was born out of early versions of FluidNC and weird behavior that was seen.
In theory, it makes sense, however, I was not ever able to correlate any difference in memory/performance between the 2 modes myself.
I also am not the heaviest of users.
Many use AP mode here with success, and have no issues.
STA mode also has it’s benefits, but requires a stable WiFi network out at your work area.
The FluidNC guys would say that if you don’t have a stable wifi network that reaches your machine, or if you are worried about isolating the traffic, you would be better off using any cheap old router and making a separate, stable network for your machine than using AP mode.
I have no evidence to refute their claims, but also none to confirm it.
At the moment, I am still using AP mode, and have not had any issues. I do not use it in the Captive Portal though.
I sent you a extremely stable setup, the one I used for a very long time. With all the issues you have been having I would think you would not want to touch anything for a while??