[3.3.1] Print stalls when xfce screen blank (power management) kicks in

[VanessaE]

If I have a print going, and my desktop's power manager kicks in to blank the screens, Cura starts stalling out while sending data to the printer, causing the printer to hang and stall and otherwise fail to operate smoothly, until I wake the screens back up.

I do not mean the computer "goes to sleep", nor some effect from a regular screensaver (as I don't run one).

Note that the print doesn't actually stop. It just goes in dribs and drabs until the screens turn back on.

The printer is not connected through a hub, nor to any of the monitors (which have mini-hubs in them).

No appreciable disk activity while the screens are off, and when I wake them up, my CPU graph history shows no unusually high activity, however, it does show tiny little spikes about once every second or two, for the duration of the screens' off time.

I'm guessing Cura is querying something about the video system and falling over when it doesn't get what it wants, making it hang at 100% CPU for juuuust long enough to induce a stall and put a little spike on the CPU graph, repeating every second or two.

Pronterface (with Cura's USB plugin disabled, of course) does not exhibit this problem, so I assume the hardware, drivers, OS, etc. are all working properly.

My bot does not have SD/LCD, so that's out. I do not have any other computers or computing devices to run the printer from, so it's USB from my main PC, or bust.

Application Version

3.3.1

Platform

Debian 9.3, XFCE 4.12 as provided by the standard Debian repositories.

Printer

Prusa i3 clone, running a recent-ish copy of Marlin bugfix-1.1.x.

Steps to Reproduce

Configure your power manager to turn off the screens after say 5 minutes. Start a print that runs for rather longer than that. Wait and watch.

Actual Results

Printing...Printing... [screens turn off] Prin...t.... st...all.... pri...nt.... sta...ll... pr...int.... stal..l... :smiley:

Expected results

The print proceeds without interruptions, whether the screens are on or not, so there. :smiley:

[myself248]

What a weird little bug!

Took me a minute to find the right search terms to locate this. I've been saying it's printing like William Shatner started... Narrating... The... G-code...

Happening to me too, Ubuntu 18.04.4 LTS on a Thinkpad T560. Running Cura 4.6.2 appimage.

Minimizing doesn't solve the issue for me. Prints normally while minimized with the screen on, goes into Shatner mode immediately when I lock the screen. Exactly the same as not-minimized. I also tried moving Cura to a different virtual desktop before locking the screen, no improvement there either. Still tied to screen locking.

(The question for me is, why doesn't it affect everyone?)

I'm totally sympathetic to the "Ultimaker's printers don't use USB anymore and we have bigger fish to fry" argument, but as a user, I'd very much appreciate a popup dialog or something. Just warn me that USB printing is unsupported and may ruin prints when the monitor shuts off. If I click through such a warning, okay cool, any failed prints are on me. But at least let me know I'm about to do something stupid, yeah?

Thanks everyone who's looking into this and working on it.

[asprunt]

FWIW, I am seeing this issue with Cura 4.7.1 on Arch Linux w/ XFCE 4.14. Stuttering goes away completely if I disable DPMS with

xset -dpms

Even without a fix, this thread has been very helpful to me. I was using Cura with USB printing as a stepping stone to Octoprint, and was worried stuttering was something I would just see there as well. Now I am optimistic I won't.

Thanks

[synnack]

Same here on two laptops with cura, using XFCE or MATE. printing via USB does works until the screen goes off, at which point the print is destroyed.

[seebs]

Just ran into this, Ubuntu 20.04 on a small desktop, Cura 4.10.0. Confused the heck out of me why all my prints from USB were awful if they were long or I moved away from the keyboard. Gonna try that vblank workaround. I definitely want DPMS enabled on my screen in general.

I don't know how easy or hard this is to fix properly; I'd assume that if the vblank_mode=0 thing works, setting it that way by default might be fine -- does anyone care about the vblank thing?

EDIT: the vblank_mode=0 thing doesn't work, at least for me. I wouldn't be surprised if the AppImage distribution meant that not all environment variables were making it all the way in to where they need to be.

[simmonsm]

I've just started using the Cura Linux app (4.11.0) and have this problem printing via usb as well. When I moved the mouse it resumed printing at the normal speed each time but the prints were spoiled by a thicker wall caused by the print head moving only once each second for ages while I was away. System info:

Kernel: 5.4.0-88-generic x86_64 bits: 64 compiler: gcc v: 9.3.0 Desktop: Cinnamon 4.6.7 
           wm: muffin dm: LightDM Distro: Linux Mint 20 Ulyana base: Ubuntu 20.04 focal 

[Ghostkeeper]

Another workaround for this issue, by the way, is to install the Power Management plug-in by Thopiekar. It prevents going into stand-by while USB prints are going on.

[github-actions[bot]]

Hi 👋, We are cleaning our list of issues to improve our focus. This bug seems to be older than a year, which is at least three major Cura releases ago. It also received the label Deferred indicating that we did not have time to work on it back then and haven't found time to work on it since.

If this is still a problem for you in the current version of Cura, can you please leave a comment? We will have a fresh set of eyes to look at it.

If it is not a problem anymore, you don't have to do anything, and this issue will be automatically closed in 14 days.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale. If you encounter this issue and still experience this to be a problem, you are welcome to make a fresh new issue with an updated description and screenshots.

[ghost]

So as I understand it - the engine sending g-code to the printer hangs up because the gui renderer can't update the screen because the screen is off? Brilliant. That's like saying that the engine in a car should only work when the radio is on....

Almost. All of Cura hangs because the GUI framework that Cura uses seems to lock up all Python code while the screen saver is on. From what we've seen, this is an upstream bug in PyQt5 that only occurs in Linux.

Our user base for printing via USB on Linux is about 0.08% of our total user base (by number of prints). Since this is an upstream issue it's more or less out of our power to do something about it. Maybe there are workarounds possible, but we can't warrant investing time on investigation now. When this ticket was re-opened, it should've been put on deferred to make that more clear.

I know this issue Is closed, But this issue just happened to me about 15 mins ago. Running cura 4.130-beta_AppImage on debian bookworm ( just discovered apt has a package for this now ) It was printing fine until my monitor went to low power mode (10 min timeout ). I have had other prints complete fine, Only when my screen was not showing cura's monitor dialog.

Just an observation.