A WARNING from one 3D printer user to the community about backpowering

DON'T SWITCH YOUR PRINTER OFF AND LEAVE SOMETHING CONNECTED TO USB

I have 2 almost identical setups - Creality Ender-3 Pro with BigTreeTech SKR Mini E3 V2 mainboards, BTT UPS, BTT Relay, BTT Smart Filament Sensor and PEI build surface - each with a Raspberry Pi 3B+ running OctoPrint. The only hardware differences are: one has a 0.4mm nozzle, original extruder and a BL-Touch Clone; the other, a 0.3mm nozzle, BMG clone extruder and an original BL-Touch. The custom Marlin firmware is idenical apart from a few measurements specific to each machine - E-steps, offsets, and such like. The printers are each contained in a small Creality enclosure and have been working normally.

Last night I just switched off the printers at their power supplies and left each of the Raspberrys running. The screens of the printers remained dimly backlit and I thought nothing of it. This is not the first time I have done it.

Today I have gone to switch them back on and there was an unusual smell as I opened the enclosures. No sign of a problem otherwise. I know I moved the Z-axis up on at least one of the printers so that the BL-Touch wouldn't be damaged and so that it would home correctly first time.

I went to the other room and tried to print something and as the printer tried to home their was a loud rumbling/"grinding" as the Z-axis was lowered. The homing failed and an emergency halt was shown on the relevant OctoPrint. I went and tried to fix it, switching off the printer and disconnecting the Raspberry Pi before switching it back on. The same problem occurred. I then tried the other printer and the same problem.

The only other difference is a recent update/upgrade to OctoPrint.

My guess is something to do with Marlin being setup to hold the Z-axis to avoid dropping down and damaging prints or the print surface. Has the motors been damaged? Or has the drivers for the Z-axis on the mainboards been damaged? Has the mainboard been killed?

The smell would suggest something electrical/electronic. Power is obviously being provided over the USB, but not enough to run the mainboard and display at full power, let alone the motors. Maybe something to do with the current to keep the motor from turning?! I am not in a position to test this moment as I had left it too late in the day before going to print something, as such I will be off to bed feeling rather depressed!!!

Luckily I have a Creality 1.1.4 board that came with one of the printers. Hopefully this works as it was never used by me. My first printer came with the silent 1.1.5 board but the Z stepper motor driver on that one died and needed replacing - so I decided to buy 1 more printer and 2 of everything else I wanted so that there wouldn't be a total outage if one of the printers went down - didn't expect both to go!

I don't expect OctoPrint to be the culprit but if someone can check. In the meantime I would suggest that anyone, at least with a simililar setup, disconnect the device running OctoPrint from their 3D printer BEFORE switching the printer off. Ideally I think this information/warning/advisory notice needs to somehow go out to all users, just in case.

I will update here in the next day or so. It will take more time and effort as I have a number of disabilities (going on 11 and a half years since getting Swine Flu H1N1 in 2009 - if only the bloke across the table had been wearing a face mask/covering back then!!!!). If someone else has any experience or help, let everyone know below. Also....anyone got a compatible mainboard or 2 going free?! I'm in the UK and could only afford these setups because of lockdown, being classed as extremely vulnerable and thus not having to fuel our vehicle as often.

This is well known issue and there are things to prevent this:

It's a good advice to prevent "backpowering" the printer via the Pi's USB

1 Like

The printers were put in enclosures for a number of reasons: temperature stabililty; dust reduction; stopping the cats sitting on it; and noise. As they're in a different room the noise isn't an issue, I was giving the printers a day off for good behaviour - boy, was I wrong, they'll have to do overtime to make it back up to me! (Good job the doctors stopped one of my meds - it had blocked my sense of humour and emotion.)

Light isn't an issue - I had printed a cover for the displays but was planning in future on adding Neopixel/WS2812 LEDs to the enclosure for feedback.

I am using the short USB cables that came with the SKR Minis, obviously these must have the power lines connected. I had already noted the problems with having the USB connected BEFORE switching on the printers.

As for "thinking nothing of it" the setup had accidentally been left in the same state a number of times before with no issue. Only now have they gone faulty and both at the same time - the only recent change, beside filament and what I've printed, is an update to OctoPrint...

Now you're not going to like this, but the person to blame here is your printer manufacturer, not OctoPrint.

The list of printers known to have backpowering issues is dominated by Creality. The reason is that their boards are not designed with the necessary electrical circuits for protection. From reading your posts, what may (note emphasis: I cannot be sure) happened was that the motors tried to draw current on the 5V USB line (which obviously will not work) and then this fried something.

Update to OctoPrint will not have made a difference to this problem - it cannot send power up or down USB, only commands. If the printer is connected and responding, OctoPrint cannot tell if it has it's actual power on or not.

The solutions to this problem, are well known - appreciate not by everyone, but the 'Tape the 5V pin' linked above is a very highly viewed topic on this forum. You can either:

  • Put tape on the 5V pin,
  • Buy USB adapters that cut the 5V power (cleaner, more reliable solution) - such as Power BLoughR by Brian Lough or I think TH3D make one too.
  • Buy a printer mainboard that has the necessary power protection. I believe (but don't quote me) that SKR boards and Duet boards have this, likely more but I can't remember now.

Thank you for letting us know the problems you have had with this, I think it might mean that (I will at least) be stronger in recommending this to people (especially with Creality boards)

I suggest you try to turn the Z stepper slowly while the printer is powered down and check if it makes any weird noises.
If everything sounds ok try to just move the Z axis - without homing. (doesn't matter whether you do it via display or octoprint).
If it does the same thing like before try to switch the wiring of the Z stepper with one of the other axis and try to move that axis a bit.
That way we can check if the motor or the driver is broken.

I have so far managed to get one printer out of its enclosure.

The sniff test indicated that the smell was coming from the Z-axis motor, with a typical burnt component scent, the mainboard smelled ok.

I have a Creality direct drive unit sitting around (when designing/manufacturing it some idiot measured from the inside out, instead of outside in [or vice versa], where the slots to mount the belt are supposed to go - so the belt is too short). As I found out the motor was not the same, and I rememebered that the Extruder motor runs at a different current, so I left that alone. Using the E-motor extension lead I connected the Z-axis wire to the Y-axis motor and, having edited the firmware to disable NO_MOTION_BEFORE_HOMING, was able to move the motor - thus the mainboard Z-axis driver appears OK (at least on this mainboard).

The question is what actually has gone on and I would therefore suggest that this is something that BigTreeTech should look at to improve on a future revision of the board.

My limited research did lead to one piece of information about not connecting a stepper motor directly to a DC power source, so I guess that is what happened via the USB.

I am now stuck with 2 printers out of action whilst I have to (after first checking that the 2nd printer does actually have an identical fault) wait for replacement parts.

I can see the Creality 42-34(Z) one available on Banggood - the (Z) one appearing to have the round rather than D-shaped axel - but are there better alternatives? What can I use with this setup? Voltages, currents and what about "upgrading" to a 0.9° from a 1.8° stepper motor? I am highly technical but it is still a steep learning curve.

As an aside, are the motors repairable, or is there anything worth salvaging from their innards?

And, as for the noise, it is very grindy/jittery when turned by hand - it feels a little siezed up inside and harder to turn.

It's running an SKR Mini E3 V2.0

Well, start of another day - I'll see if I have enough in me to test the 2nd printer, to see if the fault is identical.

I'm obviously so stressed about both printers being damaged that I was dreaming about the problem last night. My idea being that mainboard designers/manufactures should put a jumper (that is disabled by default) on the 5volt line of the USB, if the data connection will work without it (assuming most devices will each have their own power). The only time I could then see you using this, is if you are connecting a low-powered device from the printer - for example an ESP8266 or ESP32 being to transmit sensor data on the enclosure, such as temperature and humidity.

I was struggling to find compatible motors for the Z-axis (model Creality 42-34). When you look closely at the motors on my printer, you can see they are by at least 2 different manufactures - at least on the Y- and Z-axis of my 1st printer. Most motors for sale, at least on Amazon, had a D-shaped axel (with a flat side), instead of a round one, as well as non-matching voltage, current, and other specs - compared to the Creality-specification one. I found some on BangGood, marked 42-36(Z). They only had 2 left (so I have had to order them to get back up and running - unfortunately they won't arrive for some time).

My worry is that same-spec replacement stepper motors could experience the same fault, under the same conditions - obviously you need to mitigate against it by disconnecting anything from the USB, BEFORE switching off the printer. Assuming everything else stays the same, what do you look for in a better, more resilient motor, so that the same damage shouldn't occur again?

From my tests on the 1st printer, it would appear that the mainboard designer/manufacturer has enough protection for itself (at least in this instance with the SKR Mini E3 V2.0) but not enough against damage to other connected components - in this case, power was still going to the Z-motor (presumably 5volt DC direct from the USB).

So, was power somehow able to make its way (directly or indirectly) from the USB to the motor, or, was there enough power to the board to keep the driver/motor enabled (or at least try to)?

The question is then, where can you further mitigate in hardware or firmware?

I assume that, as the firmware is configured to stop the Z-axis from dropping down, as I understand by keeping the Z-axis stepper driver/motor enabled (and disabling the other axes and possibly extruder), that the mainboard was trying to still do this, but in a low-powered state. So, can you detect a low power state in firmware and thus stop the action that can cause damage? Otherwise you would need some hardware components to protect the I/O.

When cross-connecting wires to motors (in this case, testing the Z-axis driver by connecting the wire to the Y-axis motor) make sure you center everything (move each axis to its midpoint) - end-stops won't correlate (unless you swap them as well) and thus you might damage your printer.

In my case, the bed moved very quickly in the Y-axis and almost slammed into the end - because that is belt driven and the Z-axis is driven by a threaded rod, and thus there steps per rotation are different. A 10mm move on the Z-axis, correlated to the Y-axis moving much further - 2 or 3 such moves would have hit the end, i.e. it moved a lot more thant the 20-30mm that I asked for!

By moving everything to the middle, beforehand, you give yourself the biggest margin for error in preventing further damage, because things will have further to go before they hit something.

1 Like

You can power your Pi 4 with your built in printer supply by using a buck converter like this one:
https://www.amazon.com/gp/product/B07ZQB6S3L/

You can get some cheap XT60 connectors like these:
https://www.amazon.com/gp/product/B073QJWVVK/

Solder one end of the XT60 connector (male or female) to the buck connecter wires, and the other end u can put some spade connectors on, and use one of the open sets of positive and negative terminals in your power supply. Then it plugs and plays just like your mainboard, to the same supply. Simple installation, there is even room inside your board casing to hide this converter as I have done that in mine. I attached it along the X axis rail inside my boards stock enclosure in the center most corner.

Then the whole system then uses one power cord, and switch. No worries about having the printer half-powered or damaging your boards..

Hello @Gene!

It's always better to power the Pi by it's own power supply to prevent accidentality powering it off.
Also cheap buck converters can have their issues too.

How would one accidentally power off the PI if you were shutting down the rest of the printer? Seems only a deliberate shut off by the main switch would cut power. Also I agree adding components like cheap buck converters can have issues, but no more or less than a PI supply would. Have had several PI power supply failures over the years and no issues with bucks as of yet, I would imagine even with a few failures in the future I would be on par with genuine PI supply failures, and they cost about the same. I believe that even with the risks, the suggestion I made would solve the OP's problem with PI usb powering the mainboard unintentionally.. BUT, I digress, you guys are the experts here.. (Also I did just notice he was running PI3's not 4's so the converter I posted wont work for him, he would need this version - https://www.amazon.com/SMAKN®-Converter-Supply-Module-OUTPUT/dp/B00R5JL8WI/ )

Maybe that is the reason? Most people power off their printer while not printing.

The printer does not have an operating system running off of its SD card and rarely, if ever, actively writes to the SD card. Turning off the power to the printer might ruin an active print.

The RPi does have an operating system (filesystem) running off of its SD and actively reads and writes to it. Turning off the power to the RPi while the filesystem is active can corrupt the filesystem. You may not be printing anything, but there's still a lot of background processes running. To prevent filesystem corruption, the RPi needs to be "shutdown" first.

The power draw from an idle printer is fairly low, but the power draw on an idle RPi is significantly lower. I leave my RPi on and use it (with a plugin and a smart plug) to turn my printer on and off. I often connect to the RPi without turning the printer on.

afaik the power loss recovering feature logs the position all the time

mine draws about 9 Watt

I'll have to take your word for it. I do, however, find it odd that the SD card is used for this, I'd expect it to go to a non-volatile memory location like the EEPROM.

In any case, I suspect that most people will not be turning their printer off in the middle of printing. Same with the RPi but in that case, its the background stuff that might get you.

It's Creality - it's never quite logical with their firmware. It's a hack to get power loss recovery to work without a power panic pin or similar. Logs position to a file on the SD card every layer, I never tried it before flashing mainline Marlin. EEPROM wear is a thing as well, and that's harder to replace than an SD card. IIRC there's an option for it in mainline Marlin now.

Me neither but yeah it's available in marlin

  /**
   * Continue after Power-Loss (Creality3D)
   *
   * Store the current state to the SD Card at the start of each layer
   * during SD printing. If the recovery file is found at boot time, present
   * an option on the LCD screen to continue the print from the last-known
   * point in the file.
   */
  //#define POWER_LOSS_RECOVERY
  #if ENABLED(POWER_LOSS_RECOVERY)
    #define PLR_ENABLED_DEFAULT   false // Power Loss Recovery enabled by default. (Set with 'M413 Sn' & M500)
    //#define BACKUP_POWER_SUPPLY       // Backup power / UPS to move the steppers on power loss
    //#define POWER_LOSS_RECOVER_ZHOME  // Z homing is needed for proper recovery. 99.9% of the time this should be disabled!
    //#define POWER_LOSS_ZRAISE       2 // (mm) Z axis raise on resume (on power loss with UPS)
    //#define POWER_LOSS_PIN         44 // Pin to detect power loss. Set to -1 to disable default pin on boards without module.
    //#define POWER_LOSS_STATE     HIGH // State of pin indicating power loss
    //#define POWER_LOSS_PULLUP         // Set pullup / pulldown as appropriate for your sensor
    //#define POWER_LOSS_PULLDOWN
    //#define POWER_LOSS_PURGE_LEN   20 // (mm) Length of filament to purge on resume
    //#define POWER_LOSS_RETRACT_LEN 10 // (mm) Length of filament to retract on fail. Requires backup power.

    // Without a POWER_LOSS_PIN the following option helps reduce wear on the SD card,
    // especially with "vase mode" printing. Set too high and vases cannot be continued.
    #define POWER_LOSS_MIN_Z_CHANGE 0.05 // (mm) Minimum Z change before saving power-loss data
  #endif
1 Like