[2.0.x] Creality3D Power-Loss Recovery

[thinkyhead]

This is Creality3D's power-loss recovery feature (for SD Card printing), adapted almost verbatim to the current Marlin codebase. Support has been added for delta printers, bed leveling, and the print job timer, and the code has been slightly reworked and re-organized.

Posted for review, study, and comment. This feature should be considered experimental, as it has some problems in its design and hasn't been tested with kinematic machines.

How it works: With this feature enabled, the machine state (temperatures, command queue, SD progress, etc.) is periodically (by default, once per layer) saved to a file named "BIN" on the SD card. If the power goes out during a print, then when the machine comes back to life this file is checked. If its valid_head and valid_foot are non-zero and matching, a "recovery command queue" is populated from the file and then an LCD menu is presented giving the option to Resume or Cancel.

When the print is resumed, the "recovery command queue" is drained ahead of continuing the SD print.

Caveats:

• Early reviews of this code gave some alarm because it appeared to write to the SD card after every line of G-code processed! But as it turns out, under the default settings the machine state and SD progress are only saved to the SD card at the start of each layer (after the first).
  A hidden option (SAVE_EACH_CMD_MODE) permits saving the state after every command, if you really want to stress-test your SD cards.
• Upon resume the entire current layer is repeated. This is likely to lead to pressure buildup and potentially knocking the model off the bed.
• This feature won't work for build surfaces that release the print when the bed cools down.
• The original version writes to the SD card on every Z change, so the "hop" feature would lead to several writes per-layer. This version has been modified to write to the SD card only when Z goes above the last height written, so it will write at most once per layer.

---

Counterpart to #10437

[scarmain]

Does Marlin have the ability to see if the main power is down? I know my Tevo Tarantula board stays on with the USB plugged in but no motor control.

Idea being on main poweroff transition, either use the last bit of charge to write to the card, or plug in a USB battery pack as a backup power supply to get the full SD card write in.

[peekpt]

Here's an idea:

have a voltage divider from the PSU voltage triggering an interrupt pin. (with a capacitor to debounce).
Most of PSU can hold energy enough to stay about 2 seconds ON. Well since SDcard is 3.3v I think the buck converter will have enough juice to perform the operation of writing to the SDCARD the exact location of the nozzle.

I never looked into Marlin's code but since you guys are fussing with this, you probably could add an option to detect a power break with a few lines of code.

The hardware:

• 2 resistors and a capacitor for debounce. Let's say you calculate to 3v when the power is on and when the power is about 10v it will trigger and perform all the operation
• 1 interrupt pin available.
• Maybe adding a capacitor to the 5volt rail will help

[thinkyhead]

Thanks! We do plan to implement that soon. You can find some machines that use just that sort of circuit. I personally think the best place to detect the dropped voltage would be at the AC input to the PSU, so then you have several seconds to respond.

There are some machines out now (e.g., the Alfawise U10) that include small board that detects the drop on the 12V DC line and include a fast-charging capacitor to provide extra time for shutdown. And the Alfawise U10 version of Marlin is open source, so we will probably borrow from it.

[peekpt]

well it's very easy to implement a mains detector that will work on 110 and 220v.
A transformerless power supply capacitor driving an optocoupler, the low voltage part of optocoupler rectified with a cap to transform the signal to dc and smooth it out

[systemik]

Power loss seems to work great but unfortunately consume a lot of ram. Around 1500 Bytes of Ram is used (to buffer the recovery information) and for small board such as ATmega2560 , we jump from 60% to 80% of ram on the latest 1.1 bugfix branch.
Not sure what can be done to reduce this...

[thinkyhead]

@systemik — A lot of optimization is possible. Someone just has to put in a full day or two to rewrite it.

[MasterPIC]

Anet boards have no free inputs available but...
I'm thinking about using an endstop switch (interrupt pin too) to make also these limited boards able to manage power loss...
A gcode command, useful to activate power loss detection, could make the endstop triggering the power loss routine on these boards...

And what about counting the processed gcode commands?
On next print, the printer could skip the already executed gcode commands: recovery would be not limited to SD prints...

[siana]

@peekpt this exists off the shelf as "MKS DET" board. It's used with MKS smart touchscreens to enable power resume feature in their spooler.

@MasterPIC Creality also has no power loss detection and no free inputs, so that's not a problem. It just dumps the status every layer into a cookie and if such is present, reloads it from there and can continue the print.

There's a possibility to try to detect the ATMega supply voltage slipping without consuming any pins, by doing a read of the internal voltage reference; however at that point it's unreliable to try to write to SD-card. SD-card is supplied 3.3V via a regulator from 5V that has an internal drop of up to 1.5V in cheaper display controller models. ATMega itself is specified to run down to 4.5V at 16 MHz, by that time, the SD-card voltage may reach 3V, which is a bit close for comfort.

Usually however, you expect ATMega to still perform at 16 MHz down to 3.3-3.5V or so, but not necessarily reliably, which however means an EEPROM write has a reasonable chance to succeed when an SD-card write would have failed. Especially if one had the capability to drop the frequency in an emergency down to 1 MHz or so, to give you even more room. This is not guaranteed for the common 2560, but a select grade is available that is guaranteed to run down to 1.8V at 2 MHz, and most chips might behave similarly, just not quite this good - it might end up being the same silicon, just binned. Might be good enough for an emergency feature, of course not for steady state.

Geeetech board GT2560 has two voltage probes that divide the supply voltages 11:1, one for bed (up to 24V nominal), one for the main 12V rail, so it may be possible to detect voltage sag and quickly turn off all high-power consumers, and you might still have plenty of time to do an SD-card write before the 5V/3.3V rails start actually failing.

A hypothetical possibility is saving a cookie on SD-card which just contains the file and current status settings, and not touching that during the print unless there are major non-position/non-extrusion status changes - the cookie gets deleted when the print is finished; in the EEPROM, you just need to save the position to spool forward to.

Unfortunately spooling forward is not directly compatible with Creality's approach and is very slow. Perhaps there's a way to make them complete each other by having the cookie be principally or exactly as Creality's current one, and spool forward within the layer from that.

If one were to do that, how would one get feedback as to how much has been actually printed vs. just G-code consumed and planned out?

[Grogyan]

Something that needs to be brought up again, is the internal voltage reference is used for making sure the ADC read back values are kept consistent.
So while you can detect the internal voltage reference drop, the ADCs will also change, and thus your thermistor readings will be off.

[MasterPIC]

I think XY endstops are pretty useless while printing.
So why not using an endstop to trigger the power loss routine (in case of missing free inputs)?
By opting for this solution the MCU should be able to store the required state variables to EEPROM, including the coordinates of the vertex of the last segment successfully extruded.
I'm currently using a dual power supply (the heaters are powered by a dedicated PSU), another reason why I think the printer should be able to rise the nozzle just a few millimeters and store its state in EEPROM...
On next power-up the printer could also limit to XY homing and then move the nozzle to the stored (and still raised) position and show recovered position by LCD to allow the user to send the remaining g-code commands...
I think limiting the double extrusion on the last (partially executed) segment would cause no pressure buildup...