› ›

Resume print after comms failure

dot_bobdot_bob
in Feature Requests
Having the ability to resume a print after a communication failure.  Perhaps create a log of all failed prints and their last acknowledged line of g-code.  Then have the ability to resume the print at that location in gcode.  It would probably need the ability to reheat the bed and nozzle before resuming.  Perhaps also have the option to run a custom gcode script before resuming as well.

This would allow print resuming if the power fails and you have a UPS on your computer, a battery backed RPI, or after a simple comms glitch, etc...

The Raise3d N2/N2+ has a controller / touch ui that is similar to a battery backed RPI that does this if the power fails.

-Rob

Comments

  • RepetierRepetier
    If the printer has no special restart store this is only possible in a few cases. Firmware needs to preserve position so on reconnect where printer resets it can restore position. If this doe snot happen you need to rehome and since most printers home to z-min they have a good chance to crash into the printed part. As you sad to store on connection error means we can not ask firmware where it stopped any more.

    In next release we have a history. I will see if I can add something like position in the history notes and maybe add a @continueAt command to skip lines. But as I said it requires you to be able to rehome to continue.
  • Chadr619Chadr619
    edited June 2017
    Other problem with restoring/resuming after power fail is that printers with Mesh Bed Leveling will need to go through that process again. However it is not able to do that process due to a print already on the bed.

    Unless the printers firmware can retain (or send) from history what the last mesh bed leveling values were, it would not be able to restore/resume the print no matter how much history you have from the previous g-code.

    Trust me, it would be awesome if we could get this, however most printers are a one way street in regards to data.
  • RepetierRepetier
    For this reason repetier-firmware stores bed leveling in eeprom (S2 parameter) so you could just rehome to z max and print. But most users do hate z max homing as it takes some seconds.

    Next server release will put in history log at which line and layer the print stopped so you have the chance to prepare a print for continue if physical possible.
  • Chadr619Chadr619
    Nice to know that bed leveling is stored in Rep firmware. Its going to be a while, but my next build I plan on using rep firmware to see how it works. Thanks!
  • BwasloBwaslo
    Given how long it takes for the bed and nozzle to heat up, that time could also be spent homing to Zmax without any real loss in time.  Sounds like a great thing to have.  I'm already thinking of how to mod my printer for Zmax homing
  • dot_bobdot_bob
    If it was just a communication hiccup the printer will still know it's position.  As far as mesh bed leveling goes many of the firmware's are starting to store the mesh in EEPROM it wouldn't take much to recall it.  I use UBL with marlin which stores the mesh in eeprom.  Often I use a fade height so it wouldn't be using a mesh above that anyway.

    Most printers won't loose their physical Z position if power is lost and the server would know the last acknowledged z position.  You could move the Z axis up say 5-10mm home the X and Y and reload the z position.  If all else fails let the user manually set the level of the Z axis and like you would on a CNC machine.  Again if you have the feature firmware support will come.

  • RepetierRepetier
    It's a bit tricky but we could store z on connect and add a server side command @restoreZ that does this. G92 is not enough here as G92 does not change the coordinates you see. But with a server command that you could add in connect script or send manually it could fix the inside position as well. If oyu then got up or whatever is up to you.
Sign In or Register to comment.