[1.1.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.

[Grogyan]

This is a great initial starting point.
I assume with the default mode of checking once per layer, that this logic is better suited for UPS connected printers?

[thinkyhead]

UPS connected printers?

AFAICT it will do the very same power-loss thing, but it will peter out when the UPS runs out of juice instead of when the wall plug stops sending power.

[systemik]

Hi, Thanks for the hard work on the firmware. I've tried to implement the power outage and adapt it to the anycubic i3 mega (with detection of the outage at the board level and big caps to do the saving on SD properly).

I do have an issue and I wonder if this is bad coding on my side or a missing bit in the code you've given. Here is the issue:

All works fine. On power loss, the information is saved. When resuming the print, the command are queued and the print restart but the issue is that the print start at +30 in Z and I print in air ...

After a bit of troubleshooting, I think that this is due to the "G28 X Y" command which will use the "Z_HOMING_HEIGHT" from the configuration file (defined at 30 on my config). When X and Y homing is finished, the Z is at +30 and print start with wrong value. Is my understanding correct? Should we then diminish the Z with the value of Z_HOMING_HEIGHT when doing the G92 ?

[thinkyhead]

Ah yes. G28 is predictable for Creality's own firmware, but for the main Marlin branch it can have many behaviors. So, this will need to work around that by some new method. It would be best if it didn't do the raise, but currently there's no built-in method to prevent it. The simplest way will be to add a special parameter to G28 that skips the raise.

[systemik]

That's what I thought ... As this is well coded , the debug function helped me a lot to understand the issue.
Maybe another thing to consider with "X_MIN_POS" . This is define at -5 on my config and when homing, you are then not at 0 for the X when doing the G92. All this config value for homing can shift the resume of the print. (if I understand correctly).

[thinkyhead]

After G28 X Y the current XY will be set to X_HOME_POS, Y_HOME_POS. Some machines home to max, after all, so it would not be sensible to force the position to 0,0.

[ghost]

@thinkyhead

We have an alternative solution for power failure on Marlin which uses resources on minimum and works flawlessly. It uses Zmax Switch, a relay (optional), power outage detection sensor, a tiny 12V (1.3AH) battery. I did not pushed this to Marlin because it only supports Cartesian. Maybe it could help. If you like, I can send the source. Below is the detailed explanation:

1. Z_MAX_POS is recorded in EEPROM.
2. A function and gcode added for determining Z_MAX_POS by probing the Z_MIN and Z_MAX sequentially. Using this function the user is able to determine and record the new Z_MAX_POS whenever a physical bed levelling is done or nozzle is changed or a limitswitch has moved.
3. A new option is added to the G28 which does the homing towards Z_Max. We find it simpler and more effective to make the homing towards Z_Min. Although the homing is setup to be done towards Z_Min in certain cases, such as power failure, homing can be done towards Z_Max.
4. Whenever a power failure is detected via the power outage detection sensor.
   i. Temperatures and fan speed are recorded.
   ii. Heaters are shutdown.
   iii. The ongoing move is completed with the battery power.
   iv. The last position of the head is recorded.
   v. Filament retracted. The head is lift up and parked away from the print.
   vi. A new gcode file is created. Heatup commands are written to the file. Home X, Y and Home towards Z_max gcode written. Movement to the last position is written.
   vii. The command lines which were fed to the ring buffer is written to the file.
   viii. Referral to the original gcode file pointing to the last read byte is written to the file.
   ix. If print recording is finished and the extruder temperatures are below 50 C the relay cuts the battery power and the machine shuts down.

After power failure user checks the model decides whether to continue the print or not. In order to continue with the print, the newly created gcode file should be chosen for print.

I have tried using big power capacitors. It did not work. The power was not sufficient for creating the new file on SD.

Tried powerbank for just powering the controller. It worked for creating the file, but without completing the last move. The position data was not determined without error and not being able to move the printhead from the model created defects which were not acceptable for us.

A battery solves all of the problems besides it enables us to power the extruder fans until cooldown preventing any possible clogs.

Here is a demonstration of the process.

[thinkyhead]

@Rigid3D — Sounds good! I would like to have the source code, although I might not get it integrated into Marlin very quickly, since I have a busy week ahead. I may only study it and borrow the best ideas.

Most of the save state procedure you describe is exactly what Marlin now does, except our current implementation (coming from Creality3D's subcontractor) isn't very good and wastes SRAM. I plan to get rid of the BIN file and use a proper G-code file, which will also include the resume print command that opens the correct file and sets the correct file position:

• M32 P S[pos] /path/to/file.gco

As for your Z-max endstop stuff, well of course people have a wide variety of machines, and we have to be able to accommodate all of them. So, of course it can only work if users have all the right hardware, and the Z-max homing behavior would have to be optional.

We find it simpler and more effective to make the homing towards Z_Min.

Homing towards Z-min on power failure? That's not just ineffective, it is impossible! It would crush the print on the bed. So on power failure we just home XY and we assume that Z is still at the (last-) saved position. For delta, we are required to home towards Z-max when homing at all. If a machine happens to have a Z-max endstop, then sure, we can include Z on homing after power-loss. But it really should not be needed on the majority of setups.

---

Anyway, I look forward to seeing what you've done, and I will take it all into consideration and apply all its best features as I overhaul the power-loss-recovery code!

[xC0000005]

Interesting I’d taken an entirely different tack before Creatality’s source was released. The printer I have doesn’t have an easy-towrite eeprom, and honestly, I never thought of using a file. Instead, I changed it so if you can home the printer, you can afterwards adjust the location of the nozzle so it’s right on top of the model, then start a Z-based-recovery print. The command parser plays through non-movement related commands, thus resetting the temperature and fan rates and so on from the original gcode file. When the file catches up to a Z height equal to the current height, it begins actually executing the printing. It’s slower than a file based recovery because of the play-through and relies on being able to home, but it works even if recovery wasn’t enabled, so it’s proven useful in a few cases where long-running prints went haywire or ran out of filament. The best source of truth for where the print stopped is the model on the print-bed, sort of.

…

On May 16, 2018, at 1:30 AM, Scott Lahteine ***@***.***> wrote: @Rigid3D <https://github.com/Rigid3D> — Sounds good! I would like to have the source code, although I might not get it integrated into Marlin very quickly, since I have a busy week ahead. I may only study it and borrow the best ideas. Most of the save state procedure you describe is exactly what Marlin now does, except our current implementation (coming from Creality3D's subcontractor) isn't very good and wastes SRAM. I plan to get rid of the BIN file and use a proper G-code file, which will also include the resume print command that opens the correct file and sets the correct file position (M32 S[pos] /path/to/file.gco) to resume the print (M24). As for your Z-max endstop stuff, well of course people have a wide variety of machines, and we have to be able to accommodate all of them. So, of course it can only work if users have all the right hardware, and the Z-max homing behavior would have to be optional. We find it simpler and more effective to make the homing towards Z_Min. Homing towards Z-min on power failure? That's not just ineffective, it is impossible! It would crush the print on the bed. So on power failure we just home XY and we assume that Z is still at the (last-) saved position. For delta, we are required to home towards Z-max when homing at all. If a machine happens to have a Z-max endstop, then sure, we can include Z on homing after power-loss. But it really should not be needed on the majority of setups. Anyway, I look forward to seeing what you've done, and I will take it all into consideration and apply all its best features as I overhaul the power-loss-recovery code! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10437 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeppcRnZVpRixIfv5a8obNjmyyDesv49ks5ty-OYgaJpZM4TXub8>.

[ghost]

@thinkyhead

Below commit includes the changes related with our power failure algorithm. Since we are using this internally some parts are included in the code instead of configuration.

I believe rehoming the machine for X, Y and Z before resuming after a power failure is important. A well calibrated machine would loose its position on Z.

https://github.com/Rigid3D/Marlin/commit/3d14a5017a9169be079ec8eda15aef7edd5e6572

[thinkyhead]

Below commit includes the changes related with our power failure algorithm.

Awesome, thanks!

A well calibrated machine would [lose] its position on Z.

Certainly, if there's a way to home Z to max, we can include that option. But most Mendel users only have a Z min endstop, and as a result we must make it able to work with that limitation.