I have a weird bug. When I’m running my machine in AP mode (off my house wifi) and my laptop screen goes to sleep, the job pauses. It’s really repeatable: it happens every time, and resumes as soon as my screen unlocks.
I’m using MacOS and Safari.
Anyone else seen this?
Those are generally mutually exclusive scenarios. Which are you doing?
AP mode is FluidNC is the Access Point.
STA mode is when FluidNC connects to some other Access Point. Usually your home or ship WiFi.
Sorry my mistake, I got it backwards. I must be in STA mode. The thing I know is true is that it’s on my house wifi.
Got it.
How is the system configured for status reporting?
That seems the only place you could be getting an interaction that would come from your Web UI client going out to lunch.
Are you copying your gcode to the SD card or are you streaming it over wifi from your laptop?
Why would the controller be connected to USB?
Also this;
I copy the file over wifi to the SD card, and then run from the SD card. I had no idea you could stream gcode without doing this!
How odd. If you start a job and close your browser what happens?
There’s a free app that sits nicely in the menu bar called Amphetamine. It is quite elegant and will prevent sleep either for a set time or until you shut down the app you are using.
Highly recommended by me after decades of using it!
You don’t want to do this. That’s why I was hoping you weren’t.
I’m not understanding why your job is pausing when your computer goes to sleep. It should keep right on going.
Like @MakerJim asked, I am curious how status reporting is setup, whether that’s polling or auto-reporting and if it makes a difference.
While I am not suggesting to update to FluidNC 4.0 yet, that version uses async web server and websockets. Note these details from the FluidNC github readme.
The goal behind implementing async was to fix the issue where if any TCP client die without sending a gracefull disconnection during a job operation (think about a computer going into standby, a network cable unplugged from a switch / computer, etc.), and if using auto reports (which uses websockets), this will hang the job for some time. Based on preliminary testings, this new async mplementation does seem more rebust to these types of disconnections.
