Pause and Resume didn't do what I hoped

[ChrisGill 0]

I realise this is probably my own stupid fault but ...

I'm using Cura 4.8.0 on a Creality Ender 5. I was running a small print from my laptop and the battery was well charged so I didn't plug it in. I forgot all about the laptop going to sleep, which it did at 90% of the print run. I spotted it quite quickly and thought I might get away with clicking Pause and then Resume in Cura. It brought the bed and nozle back up to temperature and homed the print head so X, Y and Z were all back to zero. It then drew another lead-in line (or whatever the correct term is). I was a bit worried when it drew another skirt on top of the first one and then it crashed into the model as I was scrabbling to hit Pause again and then Abort. Cura, however, moved on from 90% to 91% during this so I presume it was still working through the code.

I'm sure the answer is "don't let the laptop get sleepy" but I'd like to understand what actually happened.

Is there possibly an enhancement opportunity - stop the laptop sleeping? Windows 10 in this case. I got it working quite successfully in some brewery software I worked on a few years ago.

Thanks

[GregValiant 1,436]

This comes up a lot.  Printing from the SD card is pretty bulletproof.  Cura is a great slicer but a poor print server.  If you insist on doing remote printing you should move to the Octoprint/PI setup. 

 

In your case the printer was only doing what it was told on a line-by-line basis.  When Cura quit sending, the printer waited patiently and then started timing out on the steppers and heaters from lack of activity.  There was no way for it to know there might be more gcode coming in.  So the question is what happened to Cura when the laptop went to sleep.  Did it bother to put in a bookmark for a restart point?  Probably not if Windows just stuck it's head in the door and said "go to sleep now" and shut off the lights. 

 

Maybe somebody from the Cura team knows what happened to Cura when the laptop went to sleep.   When printing from the SD card, the printer writes information to the SD card to keep track of where it is in the gcode file.  That way it knows a restart point.  I think the problem is that the original print wasn't paused - it was interrupted suddenly like a power failure.

 

I work from a laptop and it never sleeps, powers off, it doesn't even have a screen saver.  I leave the USB cable connected to the printer all the time and run SD card printing and print tuning from my own software on the laptop.  If I run an over-night print, I pull the laptop off the network just in case Microsoft pushes an update during the night.  With the USB cable plugged in the printer is vulnerable to restarts of the laptop because they always cause a reboot of the printer.

 

SD card or Octoprint/PI.  Later we will discuss the benefits of using the tail ends of filament rolls to practice disaster recovery.  You now know about one, but there are others lurking around.

 

Edited December 19, 2020 by GregValiant

[ChrisGill 0]

Thanks Greg

I'm learning all the time so it's definitely useful to know about the printer timeouts and the write-back to the SD card. I agree, I would normally run from the SD card and run up & down stairs a lot but, being a small print, I thought I could get away with it. I have my laptop set to not sleep when powered up and I also don't have a screen saver. Ah well, lesson learned.

 

That's a good idea about using left-over lengths of filament. I haven't quite got to the end of the first one yet so I'm bound to hit that problem before too long.

[GregValiant 1,436]

Every once in a while I print a calibration cube.  There will be a pause at height in there and I'll throw in a pause from the LCD, from my own software,  and practice recovering from an aborted print.  There are certain steps you can take to save a print, but it certainly isn't possible for every mess we make.