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

still in “work in progress” but enough advanced to congrat it !
this is a new tablet extension with a gcode visualiser added !!

at this page :
https://github.com/MitchBradley/WebUI-tablet-extension

2 Likes

It’s not very theme friendly. I’ll have to poke it a bit.

Edit: Looks like the tablet.css file should just be updated to set background-color: white under #tablettab. That at least will override a dark theme background.

I’m still going to try and theme this.

1 Like

oh yes please !
with some stylish boutons and background !
i juste seen the css file just here

I’m just trying to make it look like it somewhat belongs with the dark theme I created.

I’m honestly not sure I’ll use this extension at all. I’m not sure a tablet mode is really necessary given the customization options for the dashboard. The only two features I like are the gcode previewer, which is really only useful to me to verify where the origin is set (which for me 99% of the time is the bottom left corner), and being able to quickly go to a specific position (which I can just type in a basic gcode command).

I’m curious if I can turn the gcode previewer into an extension that would be a panel on the dashboard.

3 Likes

iam agree with you about this
for me should be great to get a 3d synced gcode viewer
and a Gcode previewer.

the other commands are not really helpfull

oh should be great !

1 Like

I third this opinion!

1 Like

Looking at this tablet extension a little closer, I see that it will actually scroll the gcode showing the currently executing line number. However, it doesn’t because it doesn’t have the line number. It seems like it could be useful to know the last executed line number along with position that it already outputs for recovery purposes. The gcode visualizer shows the current position as it runs, but that’s just overlaying the position.

Based on what I can tell, this should be possible to setup in a couple steps:

  1. Update config.yaml to set use_line_numbers = true

    Top Level Config Items | Wiki.js (fluidnc.com)
  2. Prefix gcode lines with NXXX.
    image
    Supported Gcodes | Wiki.js (fluidnc.com)
    I’m not seeing a way to do that in directly in Estlcam. It would be an easy script. Perhaps an external post-processor could be created.

Has anyone messed with line numbers? Think it’s worth it?

2 Likes