Wow, I just figured out why I’ve been having to reinstall my printers firmware lately. I forgot that moving the x and y axis while the printer is un plugged will corrupt it. Saw this when i just finnished a print, unplugged it so i didn’t have to wait for the motors to turn off and moved it around. When i replied it in my computer registered it as a new device. Pain the butt to reload it but at least i know what the cause is.
@Watterott_electronic , would http://www.watterott.com/en/SilentStepStick-Protector protect against something like this?
@ThantiK mabey. But know that i know what’s causing it, id rather just not do that, than tamper with the boards I’m pretty bad with electronics
bah, looks like you’ve got a printrbot anyways; which doesn’t use pololu-style breakouts. Boo…
is this with all firmware and controllers? I am mystified, I have moved the axis on delta and cartesian many times with the power off and with the power completely unplugged and never noticed a need to reinstall firmware. Can I get a little more detail on this? Is this from a generated voltage from turning the stepper?
Honestly kind of baffling to me why people have issues with this, since the motor has to spin like 400+ RPM to generate more than the 12 volts your power supply applies to the exact same circuit.
@AlohaMilton one theory I have is that an attached LCD prevents damage by sucking up the generated power by lighting up the backlight.
Although in this specific case, I suspect the problem is the brownout detection fuse bit on the chip not being set properly, so it’s starting up with insufficient voltage and then crashing out.
@AlohaMilton i belive so. This also happens in pi’s i belive they can corrupt the sd card is a power back flow happens
There might be a solution for this. One method could be to control the power going to the stepper motors. Vmot could be switched through a mosfet either by the mcu or a delay circuit. No return path means no current flow.
@Stephanie_A Gotta be careful, because if the motors can’t send power back to the PSU during fast decay braking, you’ll blow up the drivers’ bulk capacitors.
I think the first thing you would want to try is getting an AVR programmer and setting the brownout detection to the proper value. Many controller manufacturers forget to do that. It’s not just a stepper voltage generation thing, while your PSU is turning off the voltage can spend time in the “unreliable operation” range long enough to cause issues.
Laine (original printrboard designer) always scolded me for moving the axis for this reason. But I’ve never confirmed I’ve ruined even one board doing this. The LCD add-on may change this but I doubt it. Let us know if we can help… since I am obviously no help at the moment.
Brook
@Brook_Drumm thanks for the offer, as far as i can tell the board itself is fine but the firmware must be reloaded. This has only happened 3 times so now that i know what’s causing it i can prevent it
Hmmm. Well, best of luck! We are here if you need us!
We’ve done extensive testing on Printrbot’s Printrboards (Rev D - F6) and have found that no matter what we do to them, they are not damaged by moving an axis while off.
We have seen two bad boards that could not hold their eeprom consistently, but determined that it was a bad part from Atmel. Replacing the board fixed the issue.
@William_Steele so a replacement board will help? I will check when i go home after i reload the firware. I only have had this problem recently so maney something went bad.
Unless you’re setup is doing something entirely different, I don’t see the motors causing an issue. Our system (Polar3D) does mechanically limit how far and how fast the motors move, but we specifically tested for that exact failure mode due to those same rumors, and have not had a single failure like it.
If you can’t get to bottom of it, we can try s new board. I have heard some USB hubs cause failure… maybe improper voltage??