After reloading I can see the files uploaded to the board.
If I select the larger one and most of the time when I select the smaller one it will also give me that timeout message, but a moment later i can see that the cut paths have loaded as they are displayed.
I have not had time to dive into the code much but it seems like this is related to some missed heartbeats since the esp or browser is probably processing the NC code and misses a few beats. Perhaps we should have it double-check if the other has come back after throwing that error that communications have recovered.
Since the NC file is on the maslow, can I just run them directly from the FluidNC side?
Yep, that timeout is tied to “pings” coming to the web ui from maslow (on a websocket, that also supplies the “serial messages”) and is currently hardcoded to 20 seconds. I would think we could bump this up or make it user configurable or even turn it off during the gcode loading process… It is possible that the code sending the gcode to the browser is neglecting sending these “ping” messages during the transmission to the browser.
What sort of device are you running the web browser on? How long after the message pops up do you see the gcode appear?
I may be able to get you a quick html.gz that has a longer timeout if you want or show you how to build one yourself.
Actually, it looks like the preferences dialog has support for turning this “connection monitoring” off that has been hidden. I turned it back on here locally and it seems to work:
I’ll get a pull request in today to Bar to include this option again, and I’ll see if I can see anything quick that can make this more reliable on load of large gcode files.