Disconnecting stepper motors from drivers during operation - Page 1
Forum section: electronics / projects

author: daxliniere
author_rank: Regular Contributor
timestamp: March 27, 2022, 01:16:56 am
content: Hello,I'm working on a product that drives a milling machine's manual cross-slide bed. From my experience the TMC2209 seems like an excellent choice.One issue I'm trying to find a solution to is that the cross-slide will frequently be adjusted using the hand crank. This will of course spin the attached stepper motors and send power back into the stepper drivers.I found that, in some circumstances, it can generate enough power to cause the connected microcontroller (which is not powered on) to light up. This indicates that the current being generated by the movement of the stepper motors is making its way through the stepper driver.This concerns me for longevity reasons, so I had thought of the solution to use a relay to disconnect the stepper motor from the driver while it is not specifically being driven. But from my research, I have learned that disconnecting the stepper motor while power is applied to the TMC2209 will fry the driver.How could I address this issue? Would it be enough to use the relay to substitute a dummy load for the bipolar coils of the stepper motor? Or is there a better solution?Thanks in advance,​​​​​​​Dax Liniere.

author: amyk
author_rank: Super Contributor
timestamp: March 27, 2022, 03:19:38 am
content: A mechanical solution might be better --- a clutch that disconnects the motor drive (and connects the crank) when it's manually actuated. Also stops the manual crank from spinning and catching on or hitting things while the autofeed is running.

author: Ian.M
author_rank: Super Contributor
timestamp: March 27, 2022, 03:44:08 am
content: If for any reason you can't use a mechanical solution, the TMC2209 datasheet at the bottom of page 11 explicitly notes that the motors acting as generators can back-drive VS.Quote from: page 11It does not set limits on how long for or how high a current is tolerable, but as this current will be carried by the output stage MOSFET body diodes, I would expect it to tolerate close to its continuous RMS output current rating of 1.4A without issues. If the lack of an official rating for this situation concerns you, add beefy Schottky clamping diodes to each output to keep them between VS and GND.You also need some sort of shunt regulator overvoltage limiter to keep VS under the max permissible TMC2209 supply voltage and a power diode in series with VS to prevent it back-feeding power to your MCU. There *MUST* be enough bulk decoupling after the VS blocking diode to keep VS transients under the 1V/us limit mentioned above during worst case unpowered stepper acceleration. Its desirable to let VS rise to above its normal operating voltage for the application to minimize resistance to motion due to the motors acting as generators, which also simplifies the design of the overvoltage limiter circuit.Its also probably desirable to ensure its disabled when the steppers are generating VS. This could be done by powering VCC_IO from its internal regulator 5VOUT, and providing a pullup resistor to 5VOUT on its ENN input.You then have the problem of ensuring that it control lines cant back-drive the MCU, and also translating logic levels if using a 3.3V MCU. One approach would be to use MOSFET level shifters as used for I2C bus applications, e.g. the classic Philips AN97055 circuit:Pullup resistor values depend on applicationbut for all except its PDN_UART pin being used bidirectionally it would be preferable to use a dual supply level translator which supports partial power-down mode e.g. 74LVC1G45 or 74LVC2G45 with their EN pin strapped according to the desired direction, and the TMC2209 side powered from 5VOUT. Note that apart from the ENN pullup and possible back-driving from PDN_UART, its input only control pins shouldn't require isolation from a 5V MCU.For the issue of the manual crank spinning under motor drive, it may be sufficient to simply add a push in to engage dog clutch behind the handwheel with a friction brake in the out position if the shaft carries through the dog clutch.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: March 27, 2022, 04:45:22 am
content: Granted that, maybe the chip isn't as well behaved as one would like, I haven't checked -- but the basic power flow in the situation at least is unlikely to cause problems. The output driver itself is rated to handle the current, period; at worst, its internal diodes drop a bit more voltage when disabled. (The output circuit will be a set of half-bridge circuits using MOSFETs or whatever, with internal clamp diodes; they might be driven synchronously in normal operation for lower voltage drop, or on-off and actually use the diodes normally anyway.)So, spinning the motor generates AC, which is rectified by said diodes, raising the supply voltage. This is all a very normal thing, and unlikely to draw excessive current (limited by motor winding inductance and resistance). If the MCU is powered off that, then, yeah, that'll probably happen.And as mentioned, the one thing that can/will go wrong -- assuming there isn't an earlier failure mechanism -- is, given fast enough spin, excess voltage can be generated, enough to blow the thing. This is probably much faster than the thing normally runs up to, so if you can just avoid, like, chucking up a drill to super-crank it sometimes or something, Idunno?And, the solution there is to simply clamp the excess -- a beefy zener diode or shunt regulator, or crowbar even, will do.If the MCU isn't doing anything other than waking up and blinking LEDs, it looks weird, but it doesn't really matter. What you wouldn't want it doing is, like, writing to a log in Flash/EEPROM every time it boots up, so it's putting extra wear on that. Which, Idunno, seems pretty far fetched for a motion controller, but who knows I guess?If this is a design thing, you might add a wakeup signal so that the MCU doesn't wake up and do anything until it's been told to; it might power on intermittently in the mean time, but it's locked out from doing anything like starting motion erratically, or lighting LEDs, writing files, etc. Seems like something that would be easier to solve in software than hardware. Could also have a UVLO or power-on reset delay, so the supply needs to be in the nominal range for some time (maybe 100s ms, maybe s?) before the MCU starts up, which could be done by hardware (supply monitor IC and such) or MCU (again locking out further operation until the condition has been met).If just off-the-shelf parts sort of thing, I wouldn't worry about it.Tim