Jackpot / FluidNC WebGUI

There’s really no reason, imo, to hide them by default.

It’s easier for someone to hide them if for some reason they don’t want to see that tab there.

Having the tab there doesn’t harm anything, and if someone is looking for those settings, it’s a lot harder to find them. If you make a direct decision to hide them, then you know how to get them back.

The default user won’t automatically know how to get those to appear

1 Like

Not currently. I suppose I could pretty quickly take the github version and make those 3 changes (update probe settings, remove tablet extension, add machine settings tab).

Although, I’m not quite sure I understand the appropriate probe settings. It looks like the max probe needs to be 80, not -80.

It’s executing this which I believe is equivalent to “G38.2 Z-80 F200 P0.5”:

G91
G38.2 Z-80 F200
G90
G10 L20 P0 Z0.5

I installed it, and I really really like it! Thank you so much! It looks fantastic.

2 Likes

Thanks Doug. It’s always exciting to see someone else using something you made. I’m sure you can relate.

2 Likes

I just had something kinda similar to this happen on UI V3 (FluidNC 3.7.15) and it was very weird.

Here is what I did and this is reproducible.

  1. I had the UI up on my PC and clicked to home all axes while I walked to my garage.
  2. I opened the UI on my phone, while it was still homing, and the theme and other preferences didn’t load. I got an HTTP 503 error (service unavailable) for loading preferences.json so that makes sense.
  3. Once the homing finished, I closed and reopened the UI. The theme and other preferences now loaded fine.
  4. Restart the board and everything is back to normal.

Before restarting the board, it was weird. My settings from config.yaml did not load correctly. It looks like it was loading default values. It only shows 1 motor for the Y and Z axes when there should be 2 each.

image

Yet, if I download my config.yaml file, it is correct. If you run “[ESP400]json=yes” in the terminal, it shows those same default values. It seems like it couldn’t read the config.yaml settings while homing so it loaded defaults but they never got reloaded.

What is your $HTTP/BlockDuringMotion set to?

That could be it, maybe I scrolled up too far and reloaded the screen while I was homing, getting ready to move it over to start.

My

is set to off.

$HTTP/BlockDuringMotion=ON

Yep, so it won’t serve up any files while homing when that is enabled.

Sorry mine is enabled as well. I forgot I reset everything. Mine did not come back after a power cycle, I had to re-flash, two different times now. I normally turn the blocking off, so maybe that is erasing something. I lost my theme and everything even though it was still in the memory.

But it still loaded the UI otherwise.

It doesn’t make sense to me how this could require a reflash. Did you completely wipe and reload preferences.json and config.yaml too? So, maybe it was that and not the reflash that fixed it?

I can see where if you tried to manually update some settings while they weren’t properly loaded, it would have saved those values and messed up those files. I think if you ran that save macro ($CD=config.yaml), I’d expect it to save those default values to the file.

Did it? Or was the UI already open and just needed to connect the WebSocket?

Had you opened it there before? Maybe it was just a cached version of the page that didn’t require the ESP32 to serve it up again

Ah, I think you’re correct. I did this on my PC by opening the UI, starting the probe, hitting Ctrl + F5 to force a refresh, and I got this:

image