FluidNC 3.9.9

Time for an update?
Jason and Mike’s webui3 fixes got pulled in so time to move to 3.9.9 and webui v3? This should make the config repo a little less convoluted as well.

I have used it for the entire new table base build and no issues.
I have a couple config tweaks to add including limiting the Z max speed by default.

Can anyone confirm no issues on this version?

I’ve run 3.9.9 on Jackpot V1, V2, and V3. No issues for me, but I’m not heavily using any machines at the moment; life getting in the way.

1 Like

Nice, thank you!

I might need to create a new topic here but…webui v3.

The connection to webuiv3 is just funky. Am I doing something wrong?

Android - connect to wifi, captive portal pops right up, “use this network as is”, go to 192.168.0.1 (the pop up goes away when you hit “use this network”) I use a desktop shortcut. The issue here is the use this network kills pop up so you have to open a browser to load IP.

Windows - connect to wifi, wait (sometimes I have to open browsers to trigger it), captive portal, click popup IP. The problem here is if you do not get the captive portal after the initial connection, it will fall back to another network.

Mac - I have not tried yet.
Linux - I have not tried yet.

Is there anything that can be done to simplify the initial connection?

The captive portal itself is the same function regardless of WebUI version.

If the browser is not popping up, that is not related to whether you have v2 or v3. In the end, once it pops up, it’s just loading whatever index.html.gz happens to exist.

It is not until that is loaded that the difference between v2 and v3 comes into play

Okay that makes sense. I am just trying to make the docs a little more clear.

Any shortcuts you can think of for this, automations, shortcuts? I tried google fu but there is really not much you can do for captive portals other than just registry edits. Hoping I missed something.

I know I will have to add a STA mode section for those with a good wifi signal, just trying to make this as easy as possible.

The FluidNC team- Mitch and Bart, insist pretty regularly that STA mode is the way to go and that AP is for setup only.

the V1 docs should clearly explain why the recommendation is different for V1 builds.

There also needs to be a good section in the documentation describing how to configure various systems to not switch away from a connection “without internet”.

I don’t know how to do that an all systems. Windows seems to refuse to let the settings stick. Too much emphasis on exporting all that lovely telemetry back to the cloud.

I finally got my older iPad to get comfortable with no internet. My issue there is I have to remember to turn off LTE.

Yeah, I hoped “metered connection” might help but it doesn’t seem to.

STA mode is easier for me to recommend now that the web installer has a config editor for people that lose their IP. I need to check again but last time I really played with this I had to install something in windows so it saw the fliudnc.local, bonjour I think, and that comes with a bunch of crap if you are not careful when installing. That used to be my major issue with STA. I will look into it again, hopefully in a little bit here today. Hard to know unless I get a fresh computer that I have not messed with.

And of course there are still the shops with no connection. That have to use AP

1 Like

Any way to get the color back into the terminal output, in V3? Kinda makes it easier to read. Not a deal breaker by any means.

The FluidNC recommendation is actually just to setup a cheap router even if it is not connected to the internet.

I’d have to look at it but that shouldn’t be too difficult.

1 Like

Yeah, I have never liked “buy more things” when the device is very capable by itself. I mean in reality we are just hitting start or resume 99.9% of the time.

No big deal I was just wondering if I missed a setting. I do plan on going through all your add-on’s again and listing them in more detail when we finally make the jump to v3 full-time. You have made so many good tweaks, I am sure some should be default for us.

1 Like

maybe tomorrow…

2 Likes

Nice. I looked at it briefly. I was looking at just coloring the whole line.

I think you removed the colon after INFO/ERR.

nah, just playing and hand typing stuff… I didn’t have any real examples to play with

I was going to also, but I looked at the WebUI2 code and this looked like the way it was done before

1 Like

I’ll also play with the terminal a bit this weekend. I remember someone complaining about it being slow.

It looks like every new message coming in, it is re-parsing and re-rendering the entire set.

So it’s just going to get worse and worse.

I’ll look at making it only process each line once and only render new lines when the content changes, maybe some virtual scrolling, etc.

Also maybe a setting so you only keep the last x messages in the terminal and roll them off the top, so it doesn’t just eat RAM for an entire job…

4 Likes

Sweet. These are significant steps forward.

Looks like it already had a weird limiting system where it would limit to either 300 or 600 based on whether auto scroll is enabled.

So it’s just the reprocessing I guess.

I have a new rendering system implemented that should be a bit better. I’ll do some more testing tomorrow

1 Like

OK. I think it’s all working ok.

  • restored color scheme in Terminal from WebUI 2
  • implemented cached rendering so it doesn’t re-render the entire message stack on every update
  • added Max Terminal Messages setting for control. default is 400

If someone wants to give it a test, you can pick up the build artifact here: index.html.gz.zip (see next message)

You’ll need to unzip the .zip to get access to the .gz file to put on the ESP32

I only have the ability to run it in the simulator right now, but if a few people can put it through its paces, I’ll make it official

I have only a disconnected ESP32 to test with right now, but seems ok

1 Like

Sorry, I made some changes to the formatting, so there is a new version here: index.html.gz.zip

1 Like