POWER_LOSS_RECOVERY does not work correctly; despite PLR file being stored properly on USB key during print, after a power loss event, the printer never offers to resume the print from the file.

[SwiftNinja]

As the title suggests. On an Archim2 board with a USB Port (Lulzbot design; source here http://download.lulzbot.com/TAZ/TAZ_Pro/v1.0.7/production_parts/electronics/usb_reader/) with the RepRap blue/white display and belted Z (so it has the 'move to top' initialization in the STARTUP_COMMANDS)

Steps to reproduce.

• Enable POWER_LOSS_RECOVERY in firmware & update printer firmware.
• Confirm "Power Loss Recovery" is turned "On" in the menu.
• Put a file to print on a USB key
• Insert USB Key
• Start Print
• Wait for, let's say, 5 layers to print.
• Shut Printer Off; Wait 5 seconds
• Turn Printer back on
• Wait for printer to home Z (belted design; running STARTUP_COMMANDS)
• "Media Inserted" Appears automatically
• .... no "resume print" option appears.
• Take USB Key, put in your computer, check the filesystem: PLR file exists and was written properly.

Expected result: Resume print option appears.

This may be an issue that is also present on the main marlin 2.0.x branch; I saw someone do a commit that supposedly fixes problems with resume when the SD/USB interface device takes a moment to mount. (I guess they weren't waiting for successful mount). I'm not sure if this is related, or if this is a separate issue, but it doesn't work on your current DrunkenOctopus Build.

Thanks for your attention! :)

[marciot]

Well, power loss recovery is a sure fire way to damage your USB drive. It's not a feature I recommend anyway.

[SwiftNinja]

Appreciate the response.

The USB Power recovery bits only intermittently save progress - once per layer, depending on configuration. Default is Z change >= 0.5mm. So the write lifecycle is really not that bad.

Furthermore, I can say with absolute confidence that it is cheaper for me to have to occasionally replace a cheap USB drive due to cell wear than it is for me to replace the filament used in a Carbon Fiber Nylon 12 long-running print that fails, for example.

It's an option, and it can be toggled (enabled/disabled) direct from the on-screen menu, so to further counter your argument against its usage - users can choose to have it off all the time, therefore removing any cell wear issue, except when they need a large print.

The feature has significant value; I personally think it should be addressed, and it's something users of Marlin have called for for a very long time, so the opportunity is here. The opportunity is there, the implementation is there, the trade-offs are well understood, and it can save filament, time, and therefore money from the garbage; and the only things stopping it is likely some mundane bug that should be fixed anyways...

[marciot]

The other reason this doesn't exist is because the TAZ Pro menu doesn't even support that feature, so by all accounts you wouldn't be able to use the feature anyway. You do have an unusual setup -- using the USB drive with a RepRap Discount display isn't something I even thought was possible! :astonished:

[SwiftNinja]

Well, regardless of USB, I have a suspicion the current implementation of PLR doesn't work with the SD card, either, but that's a hypothesis. I can switch over to SD if you need me to confirm for 100%.

I agree, I'm running an entirely custom / "unique" setup. But it drives me absolutely batty that PLR is missing from these printers in 2020. I realize that it's an arguably inferior "hack" implementation compared to what Prusa implemented with, effectively, hardware power panic, but something is better than nothing. And it's certainly a novel alternate solution to hardware overhead.

As for "Taz Pro", well, that's not exactly my goal, but you did implement the FTDI controller bits and, therefore, I presume, the menu system which also seems to be baked into FTDI. So who better than you to add it? :P I'm sure it's a sellable feature for Syndaver, so maybe you can recuperate some of your costs if you were to fix it. It'd also be a key product differentiator for the Syndaver, at least until Lulzbot catches up.

On the Taz Pro, I don't think the Z-axis can support the weight of the dual toolhead (reliably enough for PLR where it cannot move, anyhow) so the likelyhood of POWER_LOSS_RECOVERY ever working on a Taz Pro properly is, I would think, nil, in the absence of hardware changes. The 5:1 geared steppers do not seem up to the task of holding the ~1100 gram dual toolhead in place, and as near as I can tell, Lulzbot "worked around that limitation" by over-tightening the bearing holder compression on Z, effectively creating artificial drag (and, associated wear), on the Z axis. At least that's how it seems to me. The single toolhead, however, I have confidence that Z can hold in a powered off state reliably.

In short: Pleeeeassse? :P

[SwiftNinja]

I can also assist you if you need information on how to wire up the reprap discount controller (the exact one that came with the Taz 6) up to the Archim, and keep the scroll wheel working while using a Taz Pro design USB port. :) It's really straightforward - the hardest thing is having one of those USB boards on hand! :)

I have a few extra PCB's of the port printed; they just need to be parted, which I can do :P (I've already done it twice, what's one more?). So, if you need me to donate a USB board to the cause to get this fixed, let me know how I can get one to you and I'll mail it out for free.

[marciot]

I have a USB board. Without working through the details, it seems like it would a messy wiring job, but maybe I am wrong.

I guess if you document the process so that I can make my own cable and have something to test things out with I may consider investigating this.

I recommend you reach out to @jcustenborder and see if he can get you setup to write docs for drunkenoctop.us . That’s a project he had been working on.

[SwiftNinja]

It's actually really easy to get the board up and running.

Basically, off the top of my head, you run the EXT1 connector from the archim board to the EXT1 on the reprap display board, and EXT2 goes from the Archim board to the USB add-on board. EXT2 on the reprap display controller board stays unwired, except for 2 pins - these are the scroll wheel. (I have to pop the case off to count which pins it was, but I simply toned them out with a multimeter back to the scroll wheel to identify which two pins). You connect those 2 wires from those 2 pins on the reprap EXT2 controller board, to 2 open/unassigned pins on J20 - one TX, one RX. Make sure those pins aren't deactivated by the EMI mitigation code, and then assign them in the PINS_archim.h file for the scroll wheel. Then, in the main config file, just need to disable FTDI and enable the option for REPRAP_DISCOUNT_CONTROLLER_LCD or whatever it is, and enable the USB controller code. (Again, that's entirely from the top of my head).

So, in short - it's not complicated / messy at all to wire. It's 2 extra wires to J20 for the scroll wheel, EXT2 goes to the USB port, and a few option changes in Configuration.H and PINS_archim2.h

[marciot]

I suppose that would work. I was thinking you had made a Y-ribbon cable so you would not need to change pins around.

[SwiftNinja]

Alrighty, I'm assuming you have what you need then to investigate; if you need more details, let me know and I can pop the case off, take pics, and send you the config changes as well.

Either way, I do really appreciate your time and your input here, and even more so your consideration (however unlikely :P) to look at fixing it.

Cheers, mate!

[marciot]

You probably need power as well. I seem to recall that comes from EXT2.

[SwiftNinja]

Nope. No other wiring changes required. Straight Ribbon cable from Archim EXT1 -> RepRap LCD EXT1 Straight Ribbon cable from Archim EXT2 -> Lulzbot design USB Port 2 wires from Archim J20 TX/RX pair -> RepRap LCD, 2 pins on EXT2, which are (already as part of the display design) connected to the scroll wheel. (.... and then a bunch of #define changes in config.h and 2 or 3 changes in the PINS_Archim2.h) (oh, and then for static disappation, you want to ground the USB board, but that's not really required for it to function, it's required for it to stay functioning for any amount of time :P)

[marciot]

Oh. Right. Because the Archim is the only board which provides power on both ports. This was a LulzBot request to allow daisy chaining of the display and USB.

[marciot]

@SwiftNinja: One potential fix for this issue is pretty easy to implement. All that needs to happen is a call to "recovery.check()" in "ultralcd.cpp" line 1598:

// Add this to top of file
#if ENABLED(POWER_LOSS_RECOVERY)
  #include "../../feature/powerloss.h"
#endif

...
#if ENABLED(SDSUPPORT)

  void MarlinUI::media_changed(const uint8_t old_status, const uint8_t status) {
    if (old_status == status) {
      TERN_(EXTENSIBLE_UI, ExtUI::onMediaError()); // Failed to mount/unmount
      return;
    }

    if (status) {
      if (old_status < 2) {
        TERN_(EXTENSIBLE_UI, ExtUI::onMediaInserted()); // ExtUI response
        set_status_P(GET_TEXT(MSG_MEDIA_INSERTED));
        TERN_(POWER_LOSS_RECOVERY, recovery.check());  // Add this to line 1598
      }
    }
    else {
       ...
      }
    }
  ...
#endif // SDSUPPORT

However, this has the side effect of triggering a power loss check anytime media is inserted. It may also cause the recovery code to run twice unless it is removed from where ever else it is called. It's not my call to make on whether this is a good solution or not, or to workout the details, so feel free to take this info and make a suggestion upstream.

Another option would be to add a menu option for resuming a print manually. There is an undocumented gcode M1000 S to trigger a power loss recovery, so you can add that to the LCD menu using CUSTOM_USER_MENUS. This should allow you to begin a print recovery after the USB has been initialized at will.

I am closing this issue since it's really doesn't belong here. I've gave you enough info to make a suggestion or a PR upstream, if you so desire.

[SwiftNinja]

That information is very helpful; if that's all it is, I can certainly address. Appreciate the tip; I'll re-open if that ends up not resolving, but at the very least, M1000 S, if operational, is all I need to be successful!

Thanks again for your help and looking at this!! :)

[marciot]

The problem with my suggested fix is that it only works if the printer has a display. That’s the trouble with fixing anything in Marlin. It’s easy to make it work for one configuration, but hard to make it work for all!