Why no UPS support


#1

Ok, first of all, please understand that I'm pretty new to 3D printing and what I might conceive as easy is actually really hard. I'm not trying to step on anyones toes. So, with that out of the way on to the question.

Why isn't there any ups support? I just lost a print that's been going for six days because of a power outage and that wasn't fun. Even a cheap UPS can drive a rasperry pi for hours, so this could be an affordable solution for everyone. (I think.)
So, my suggestion on how the plugin would work (the printer will not be plugged to the ups since it draws too much power).

1.) Octoprint will immediately pause the print (the printer will have shut down by now anyway)
2.) Once power has been restored the printer will start again and octopi will start waiting for it to connect
3.) Temperatures are restored and the print job resumed

I realize that someone would have added this feature if it was easy. But why is it so hard? What's keeping this feature/plugin from getting added?
Thanks for your replies and thanks to all devs for making this fantastic piece of software


#2

This is just a guess, but I think none of the people that regularly develop plugins have a UPS. There's also no real standard as far as I know between UPSes how they notify the host computer (so what works with one may not work with another). Finally in many cases it will not be as simple as just setting the temperatures back and resuming; when the bed cools down far enough, prints will start popping off the bed and there's no way to recover from that.


#3

Good points!
I thought you could issue custom commands via apupsd (the ups server software). So basically have octoprint communicating/receiveing pause commands from the apupsd.
But you're absolutely right about prints popping off when the build plate cools.
I was kind of hoping that the power would be back on before the build plate had time to cool off.
Power outages are usually just a few minutes where I live.
Perhaps I should just invest in a huge battery for my ups...

Edit:
Integration with software such as this:
https://linux.die.net/man/8/apccontrol

So when the server issues a "onbattery" (the raspberry Pi is run on battery) the print gets paused.
And when the server issues a "offbattery" (the Pi is run on power again) the print resumes.


#4

This sounds like a great idea for a plugin, but I'd suggest basing it on nut rather than something APC-specific. Nut works with many flavors of UPS and thus would be more flexible.


#5

For the record, there's a slight issue with the pause situation.

In order to properly resume a print job, you need to query the pause position from the printer. Otherwise you'll skip at least one segment (and possibly more, depending on how large the printer's buffer is, and for that there's no solution).

The thing is, when you send commands to the printer, it doesn't immediately execute them. It throws them into an internal planner buffer, uses them to plan acceleration and such and then executes them some time after they were received (and acknowledged). Which means, OctoPrint has no idea where in the model you actually are, it depends on the printer's internal buffer size and also print speed. When you normally pause and have configured a proper pause script, OctoPrint will wait until all moves are finished, query the print head position and then move the head out of the way. Then on resume it will use the queried position data and move the head back to the position it was at before the pause, and only then continue with the job.

If you don't do that, you will loose whatever was in the buffer and also not return at the correct position.

If the printer gets cut from power, you cannot even query the position anymore, let alone wait for it to finish moving. This needs to be solved before any kind of UPS automation can help - or you need to put the printer behind the UPS afterall.

Additionally, keep in mind that for the steppers to hold their position they need current. If the printer's power is cut, this position is lost and you get smaller or larger layer shifts, unless you manage to rehome exactly.

And the print potentially lifting off the bed due to it cooling down was already mentioned as well.

So, long story short, a power failure has several issues to solve first before you can even start thinking about automating that.


#6

I also live where we get short time outages so what I have done is use a ups to power the printer with the exception of the heated bed. This way, the print will ride through those short blips that will kill the print, and hope the heated bed doesn't cool much to cause the lack of adhesion problem.
Has saved me a few times.

Country


#7

Ah, so much more complicated than I could ever imagine.
So there can be two solutions the way I see it.

1.) Turn off the heated bed during the power outage and continute using the printer (about 60w for my cr-10)
2.) Use Country_Bubbas solution and have the bed being heated from a separate power source. Which obviously is the easiest solution since it wouldn't require any modifications to the software.

Just a small question. The printer would still be powered via the usb port of the Pi. Would that be enough to query the position?

Thanks for the input everyone! I have learnt a lot!


#8

That hugely depends on the controller board in question (for example, the Prusa MK3 seems to not allow backpowering at all, if the PSU is off the whole board is dead on serial, though detectable), and having the printer powered from the Pi is actually more of a bug than a feature anyhow as it can cause interesting power issues.

And remember, you not only need to query position, you need to wait until the currently planned moves are finished, then query the position (M400 followed by an M114), and you definitely cannot power the steppers through USB. Just querying the position and then shutting off will make you lose possibly crucial moves (e.g. a z-change or two).

Long story short: the reason because there's no plugin yet might not only be that next to no one uses one, but also that recovery from power outage when a serial host is involved is incredibly difficult (and still tricky to pull off reliably when only printing from SD).


#9

You are of course absolutely right. Seems like there are no shortcuts to the perfect print, or saving it if something goes wrong.
Again, thanks for the reply!


#10

Technically, you could implement the same solution as is used in bigger computing centers - you would need a generator (e.g. a small diesel generator) and a PSU and of course the controlling devices. Since a 3D printer including PI and LEDs and whatever you have around the printer itself only needs about 0.5 KW, the generator should not be too expensive. But then you could print through even longer outages - as long as there is enough fuel :wink:


#11

Here are my 2 cents:

  • Connect RPI's PSU to UPS.
  • Connect printer's PSU to D-Link Smart Plug (or similar device) that is plugged into UPS.
  • Connect UPS to RPI serial/usb port

With this setup it should be possible to develop a plugin that can:

  • have a configurable parameter that will contain the maximum time that UPS can keep printer running
  • detect power outage and start internal timer countdown
  • do nothing after power outage until aforementioned maximum time expired.
  • after reaching max time switch job to PAUSE mode, stop sending commands to printer, wait until the buffer is processed (could be simple delay of 10 sec), then send command to Smart plug to power off the Printer.
  • detect that power came back
  • if power comes back before printer is paused - reset the timer and go back to "sleep" mode
  • if power comes back while print is paused - wait until Smart Plug comes up and connects to WiFi (could be tested with ping test), send the command to power On smart plug, give some time for printer MCU to boot, then reconnect and continue printing.

Plugin may have few additional configurable parameters. For example the time after which it is expected that print has popped off the bed and the job has to be killed. After killing the job, RPI may optionally gracefully shutdown itself.


#12

Surely you jest. :laugh: I wouldn't dream of putting my 3D printer straight into the wall outlet.

I'm very fond of the APC brand of UPSs, for what it's worth. The Smart-UPS variety have a serial port for controlling them—I've used this to do some fancy things in a datacenter situation like tying them into the fire-suppression gear. For a generic plugin, you'd need to allow the user to adjust the serial settings since APC changed those over different models, unfortunately.

This article does a good job of describing how to install their daemon on Raspbian.

That said, I can't imagine trying to write a brand-less plugin.

Personally, I also connect my printer to the UPS so that everything still runs during a "brown-out". I wouldn't recommend just putting the Raspberry on the UPS. I would include the heater for the bed since it's possible that a firmware might panic if the bed temperature is suddenly not responding to adjustments. I wouldn't assume that the 5V USB power from the Raspi alone could keep the printer board alive if it's lost power.

Having detected that the UPS is on standby power, it's certainly possible to pause OctoPrint, home the extruder assembly, retract the filament, save the current line number and/or current layer (noting that OctoPrint doesn't know how many lines your printer has actually printed from those in its receive buffer), serialize this information to a data file, gracefully shutdown OctoPrint, run the Raspbian shutdown command and then wait for the UPS to kick the bucket or to return to service.

What's difficult is automatically resuming from there but all I've described would be certainly more than what I have now.

What would be awesome would be to have a gcode command to query the firmware to ask it which line was the last one it executed. In this way, OctoPrint after that Pause could query the information, return it to the plugin and that also gets serialized to the data file. In theory, this FR on the Marlin firmware repository could also return this information.


#13

Then why's there no plugin yet?? :wink:

If you have the printer on the UPS, shouldn't it be possible to "just" let the printer finish what's in its buffer and then do the necessary parking and clean shutdown? Why would you need firmware query support for that?

I agree automatic resuming is harder, and would actually argue that it is not desirable (other than perhaps getting the heated bed temperature back up as quickly as possible). The state of the print(er) needs to be expected before it is safe to continue.


#14

Granted, I've lived in places where power supply from the service company was terrible (and worked in buildings where the wiring was horrible) but I'll have to say that my current apartment and city is delivering the goods. It's rare for me that I get a blackout and about the same for brownouts. The UPS is doing a great job for me, the printer and the Ethereum mining rig that's also on there. I've not had one corrupted microSD in over a year, for what it's worth.

I mention firmware-query because the original poster wants to maximize his chances of job resumption. If you're only invested at the "save my printer/microSD" level then you're right—the problem starts to look a lot more simple at that point.

Regarding drive health, the ext4 partition format is supposed to be forgiving of power failures. But I do know that Robo 3D had no less than ten microSDs which were so trashed that even I couldn't resurrect them. And not one UPS was to be seen in the room.

I'll eventually spin up a solution for job resumption since it seems like an interesting problem to me. I honestly don't print enough these days so that's on a back burner, if you will. I could see working on an APC-specific plugin, though. I trust that brand since I've worked with them for decades.


#15

Well I'd be very interested in such a plugin. Seems like APC does make the best UPCs and that they are widely supported.
So if you get around to write the plugin I'd be very happy to try it out.