[FluidNC PR#1574] Async webui

#1 – MitchBradley 于 2025-09-24

There is something I do not quite understand; perhaps you can explain the problem.

As background, [ESP… commands, notably ESP400, are synchronous in that the response data is returned via the HTTP transaction. It uses WebClient as the Channel for routing the command output to the client. In principle, it seems to me that the async web server ought to be able to handle something like that in a streaming fashion, perhaps by using chunked encoding.

What am I missing?

#2 – Gerporgl 于 2025-09-24

Yes, I know, at first I was also thinking this should be simple to do, especially with async it shouldn’t be a disadvantage.
But I cannot call “send chunked” or send data… it is a callback form the AsyncWebServer that fires as it is ready to send more chunks of data to the client.

If I could have called beginSynchronouseCommand, then called a kind of pullSynchronouseCommandChunk from within the chunked response callback passing the maxlen multiple times that would have worked.

When you call settingsexecuteline(…), it does not return until all of it is completed (even if internally it pushes it “somewhere”), and if you are inside the request handler when calling it (which is the case), then the callbacks cannot be called, so you have to find a place to hold the entire buffer, which is >32KB. It makes sense, they are only async, not multi threaded necessarily.

Other large payloads serving documents (like index.html.gz) work just fine, because you can read from a stream in chunks as the async stack is ready to send when the send buffer is good.

So in fact, if there was a version of executing a command with a response (and ideally with the json serializer included) as a stream that does things in real time that would work. I considered this idea, but that part of the FluidNC code seemed too much to change for me, and wasn’t sure it was realistic to do.

So the task in background to “fork” the settingsexecuteline seemed like the easiest that I could test, at least to see if it fixed my memory issue.

I even tried another idea to write the settingsexecuteline into a temporary file, then stream it back as a filestream… it worked too, but I did not really like writing data as a file on flash, of course. To have to store a temporary 33KB json on the local FS, and well the SD was tempting but that would make even less sense.

Again, perhaps I am missing an easier approach.

#3 – MitchBradley 于 2025-09-24

Yuck.

#4 – Gerporgl 于 2025-09-30

The last commits should now properly kick/disconnect a previous browser session on the same browser on a different tab, this should avoid any confusion if one tab did not receive message updates in the previous approach where multiple clients would be allowed to stay connected.

Reused the current id & active id logic that was there before, but limited to cases where it could cause confusion.

Tested briefly with webui3 and webui2, seems to work.

#5 – MitchBradley 于 2025-09-30

50 ms is probably too fast. It is hard to read numbers that change faster than, say, 10 times per second. 5/second is probably as fast as you could reasonably use.

#6 – MitchBradley 于 2025-09-30

For me, the most valuable thing about auto-reporting is the immediate reporting of state changes, e.g. from Run to Idle, and the reports of GCode mode changes.

#7 – Gerporgl 于 2025-09-30

> 50 ms is probably too fast. It is hard to read numbers that change faster than, say, 10 times per second. 5/second is probably as fast as you could reasonably use.

I’ll change it to 200