-
I have some Diodes Inc. ZXBM5210 motor driver ICs that I am experimenting with on breadboard, but I'm having some weird problems that I can't figure out. I have one hooked up in a circuit to a single small DC motor as per the diagram below.
The problem I'm having is two-fold:
1. When I drive the motor in reverse (switching pin 5 high), it will either immediately trip the over-current protection on my PSU (set to 700mA, which is normally plenty of headroom to run these particular motors on 12V), or will run the motor but with a frequent stutter.
2. When I drive the motor forward (pin 4 switched high), it will run the motor perfectly up until I stop, but then the IC starts drawing ~50mA of current from +5V (VDD pin), and any subsequent switching forward/reverse will immediately trip the over-current. Also, very occasionally, after a few 10's of seconds of the motor running fwd, OCP will suddenly trip, even though up until that point only around 150mA was being drawn.
The second issue in particular is puzzling me greatly.
The normal operating VDD current draw should be < 2mA when operating, and microamps when in 'standby' (i.e. not operating, both FWD & REV low). Could it be some form of latch-up?
Things I've tried:
- Another chip. No difference, both of them behave in the same way.
- Another identical motor. Also no difference, although the second one seemed to make it want to trip the OCP more than run but with stuttering.
- Adding pull-down resistors (10K) to the FWD/REV pins, in case maybe they were floating and intermittently causing both to be high, putting the driver briefly into 'brake' mode. I thought this might have explained the momentary stuttering, but didn't make any difference.
- Substituted the ZXBM5210 for an old L293E. Everything works perfectly with that and operates within the set 700mA current limit.
Things I'm worried may be impacting the situation:
- These ICs are SMD SO8 package, and for breadboarding I have them soldered to an adapter PCB with pin headers. The traces on these adapter boards are fairly thin - I estimate about 10 mil - but given there's only a few hundred mA at play, I thought it'd probably be okay, at least for testing. But maybe not?
- The diodes I'm using for flyback protection are only 'slow' 1N4007s. Normally I'd use a 1N5819 (or similar) schottky, but I don't have any right now. Have ordered some, though, to see if it makes any difference. But, they work fine for the L293E.
- Perhaps the chip may be getting too hot? But surely not with it only handling a couple-hundred mA at most steady-state?
Are any of those concerns?
So, I'm at a loss as to how to figure out what the problem is and need some help.
Anyone with any ideas?
-
You need pull-down resistors on your switches.
-
You need a bypass capacitor at Vm. The datasheet recommends something in the range of 470nF to 10uF.
I would recommend putting a small capacitor at the Vref input as well - 10nF should suffice.
Pulldowns on the direction inputs is good advice, too.
-
As I stated earlier, I already put pull-down resistors on the switch inputs, but it didn't have any effect on the issue. Tried a 10nF cap on the VREF input, but that didn't have any effect either.
I just got my schottky diodes and put those in instead of the 1N4007s. The issue has changed slightly, but not for the better.
Now when initially switching in either direction, the motor at least runs perfectly. But as before, as soon as I stop, I still get the anomalous 50mA current draw from VDD. However, I can usually run the motor again, and then when I stop the current draw goes even higher, to around 70-80mA! 
At that point, attempting to run the motor a third time trips the OCP.
Yes, I saw those mentions of caps in the datasheet, but they talk about them in context of fly-back (or 'back-rush' as they call it) voltages, so I kind of ignored it, because the diodes will handle that, right? But it was worth a try. So, because I didn't have any 0.47uF caps to hand, I tried 3x 0.1uF in parallel across VM and GND. Very happy to report that it seems to do the trick!
I don't really understand how this is solving the problem, though. How is a bypass capacitor across the motor power supply on the high side supposed to help with fly-back transients? I thought that when caps are used in that scenario, they're put on the load side, in parallel with the motor. Or is it nothing to do with fly-back voltages? Is the datasheet just terribly confused? I know I am.
Here's a question: if I were to have several of these ICs controlling several motors, would I need a bypass cap on each and every VM pin? Or could I get away with just one larger value (say, a few uF) for the whole lot? -
...
Yes, I saw those mentions of caps in the datasheet, but they talk about them in context of fly-back (or 'back-rush' as they call it) voltages, so I kind of ignored it, because the diodes will handle that, right? But it was worth a try. So, because I didn't have any 0.47uF caps to hand, I tried 3x 0.1uF in parallel across VM and GND. Very happy to report that it seems to do the trick!
I don't really understand how this is solving the problem, though. How is a bypass capacitor across the motor power supply on the high side supposed to help with fly-back transients? I thought that when caps are used in that scenario, they're put on the load side, in parallel with the motor. Or is it nothing to do with fly-back voltages? Is the datasheet just terribly confused? I know I am.
Here's a question: if I were to have several of these ICs controlling several motors, would I need a bypass cap on each and every VM pin? Or could I get away with just one larger value (say, a few uF) for the whole lot?
You need a bypass capacitor on each IC's Vm pin, preferably as close to that pin and ground/common as possible.
This capacitor filters out high frequency noise and supplies the instantaneous peak of current needed every time a transistor turns on, but it also receives an instantaneous peak of current every time the transistors turn off. Note that flyback (or freewheeling) diodes on the outputs merely provide an alternate pathway for energy stored in the motor inductance, but that energy will raise the voltage at the Vm pin until it overcomes the inductance to the nearest capacitor... hence why you need the capacitor at the Vm pin, why it needs to be as close to that pin as possible, and why its value needs to scale with motor current rating.
-
This capacitor filters out high frequency noise and supplies the instantaneous peak of current needed every time a transistor turns on, but it also receives an instantaneous peak of current every time the transistors turn off. Note that flyback (or freewheeling) diodes on the outputs merely provide an alternate pathway for energy stored in the motor inductance, but that energy will raise the voltage at the Vm pin until it overcomes the inductance to the nearest capacitor... hence why you need the capacitor at the Vm pin, why it needs to be as close to that pin as possible, and why its value needs to scale with motor current rating.
Ah, I see. So it's not only acting as a buffer for current draw at VM, but also acting as an absorption buffer for any spikes fed into the +12V rail supplying VM by the flyback diodes? Not sure what you mean by "that energy will raise the voltage at the Vm pin until it overcomes the inductance to the nearest capacitor" though. Overcomes the inductance of what?
And the reason why the cap value needs to scale with the current draw of the motor is that a larger motor will produce a bigger 'kick' of energy when it's turned off? So does that mean that there's no harm in having a larger value capacitor even for a small motor? For instance if one were to use a 10uF cap regardless. I think I may ultimately go for 1uF just to give a bit of headroom. -
Quote
So it's not only acting as a buffer for current draw at VM, but also acting as an absorption buffer for any spikes fed into the +12V rail supplying VM by the flyback diodes?
Exactly.
You have a "composite" problem here, I think. First the spikes from turn-on turn-off due to the motor inductance, but also that these overvoltages are being fed back into your power supply, making this go crazy as well.
The capacitor at VM can be any size, provided it's large enough. I'd just go for 10 uF or even larger.
-
Okay, I spoke too soon. If I rapidly and continually (i.e. every 1-2 secs) switch back-and-forth between forward and reverse for a short while, I still get the the problem with the IC getting into a state where it sits there idle but drawing 50mA. Also, when it does so, if I press my finger against the chip I can feel it getting fairly warm (which I suppose is to be expected with 50mA being burned somewhere), which can't be good. Everything continues to work after it has started doing this.
I tried swapping in a much larger cap, 47uF instead of 0.3uF, and it still occurs even then. I'm not sure what's going on here.
-
Hmmm... It is possible that the voltage at Vm or the motor output terminals kicked up high enough to result in damage (either from overvoltage itself, or from causing current to flow inside the IC along pathways it shouldn't).
Otherwise, this sort of IC tends to not behave very well on a breadboard, and misbehavior could simply be the result of a lack of groundplane and marginal decoupling. But that increased idle current consumption points towards internal damage...
-
Be aware that, when the motor is spinning full revs in the one direction, and you instantly switch the driver to the opposite, then the stored kinetic energy will be charged back into the DC bus when decelerating the motor. As you are running it on a lab supply, that energy has no other option than to charge the bus capacitance. If that is too low, then you'll have (unlimited) overvoltage for a short time, which can destroy the driver, put it into latchup, and disturb your supply. You can solve this by adding more capacitance, or by adding a beefy zener diode as overvoltage protection.
-
I had an idea earlier: that maybe this continuing problem is to do with possible overlap of FWD/REV when I'm pawing at the switches. Switch bounce may not be helping either. So, I hooked up an Arduino to control it and wrote a quick program to just loop running each direction back-and-forth for a couple of seconds. But the problem got even worse! With the Arduino controlling things, it goes into 50mA-idle-draw right after the first turn of the motor, before it even runs back the other way.
Another thing I tried was something that occurred to me after re-reading the datasheet for the umpteenth time. In the notes section entitled Motor Speed Control by DC Supply Voltage, they talk about varying VDD to alter motor speed. "Huh, surely they mean VM?" I thought. But then the thought occurred that maybe they never intended to have VM and VDD be differing voltages. (In which case, why label them differently?) The specs only give a single operating range for both (3-18V) and describe both on the pin-out as 'Power Supply Voltage'. Also, I found that Rohm do a very similar chip (but at 5x the price
) that has identical pin-out, where they label both those pins as 'VCC'. So, I hooked VDD up to the +12V supply, and also VREF (as it must be equal to VDD if not using the built-in speed control). Nothing really works at all when in this configuration! Driving it one direction trips the OCP immediately, and the other runs the motor for only a fraction of a second then stops, with the chip sat drawing 70-80mA afterwards. Aargh!
It's really starting to annoy me that I can't seem to get this chip working properly.
-
I've reread the datasheet as well, and agree that VM and VDD must be connected together.
That you still have problems might be due to the IC now being defect.
-
loop running each direction back-and-forth for a couple of seconds. But the problem got even worse!
Have you read my previous post, explaining what happens by that? -
Quote
Have you read my previous post, explaining what happens by that?
Well, I read it and it's not correct. There will be a small kickback from the stray inductance, that's all, and that should be caught by the cap.
When powering a PMDC motor, it will spin up until back EMF equals the supplied voltage (minus losses). If you remove the supply voltage, the back EMF will stay the same, it will not increase due to kinetic energy or other reasons.
-
When powering a PMDC motor, it will spin up until back EMF equals the supplied voltage (minus losses). If you remove the supply voltage, the back EMF will stay the same, it will not increase due to kinetic energy or other reasons.
If that would be the case here, I would agree with you. But my assumption here is that he spins the motor forward, and instead of removing the supply voltage (as in your case) he instantly reverses direction while the motor is still spinning. In this case the motor is forcedly decelerated and acts as a generator for this short period.
But I was also wrong in an assumption. It requires a PWM'ed controller (utilizing the motor inductance as part of a DC/DC converter) to create 4-quadrant capability, allowing to transfer back mechanical energy (braking / decelerating) to the supply. This driver does only direction and enable control. In this case, the stored mechanical energy is dissipated and dumped into motor / driver resistances. -
Quote
In this case, the stored mechanical energy is dissipated and dumped into motor / driver resistances.
Actually, it will just coast to a stop. Kinetic energy will be dissipated in friction and eddy currents - and the mechanical load, if there is one.
-
If you reverse polarity of your drive voltage (which is what the H bridge does when instantly switching from fwd to rev), the motor will certainly not coast to a stop. It will abruptly be decelerated and then accelerated in reverse, with a lot of current flow.QuoteIn this case, the stored mechanical energy is dissipated and dumped into motor / driver resistances.
Actually, it will just coast to a stop. Kinetic energy will be dissipated in friction and eddy currents - and the mechanical load, if there is one. -
Stop flogging a dead horse.
Yes, it will draw some current. But the assumption that it will dump kinetic energy and current into the supply lines is way off. 'Nuff said.
-
Stop flogging a dead horse.
Shouldn't declaring horses dead be a bilateral agreement?
Yes, it will draw some current. But the assumption that it will dump kinetic energy and current into the supply lines is way off. 'Nuff said.
I have implemented quite a few larger scale servo applications, and DC bus voltage rise from kinetic energy during braking is reality. Not in this case because no PWM, but the hint is definitely not way off.
Some reading here: https://granitedevices.com/wiki/Overvoltage_and_undervoltage_faults
-
Hello. I have the same issue. Tried every solution and still whenever I change the direction The driver goes to the current protection.
I cant understand why I have this much current when I change the direction.
And funny thing is that it doesnt occurs always. Sometimes It acts normal when I change the direction. and this is when I am using the clean voltage on each forward and reverse. The situation becomes worse when I am using PWM for the direction pins.