Part Number: DRV8803
Dear TI,
Disconnection issue occurred while reviewing Motor Driver.
We are currently testing with Zener + UFD as follows.
1. Disconnection issue Waveform
2. Zener + UFD be used
=> Can Zener + UFD be used? (At present, the zener diode is very hot. / Zener Part # '1N5359B')
=> Is there a product that can implement the Disconnection feature? (DRV8806 or DRV8860)
Part Number: DRV10987EVM
Hi,
May I know where can download DRV10987 EVM GUI parameter file?
Thanks.
Regards,
Eric
Rick,
You are correct, I meant microseconds.
So there is a delay from input to output but that should not affect the duty cycle? Additionally, there is a synchronization circuit that add 250ns to 420ns. Is my understanding correct?
Mike
Part Number: DRV8840
Hello,
We use the DRV8840 to control a brushed motor without encoder feedback. If the motor does not reach the desired location in a set time the MCU generates an error. Because there is no motor feedback to control the speed we use a constant duty cycle to drive the motor. During development this approached worked well however we received some new DRV8840 parts with a different lot code that have different output characteristics. The output duty cycle is lower than previous lot codes and this causes the motor to move slower which generates a timing error. The datasheet doesn't discuss the tolerance of input duty cycle to output duty cycle. Is there a specification for this parameter? What is the recommended guidance for dealing with duty cycle tolerance?
Regards,
Michael
James - I don't have a scope, or diff probes needed to capture the whole picture all at once. But I will attempt to do each leg separately, using waveform math.
Jamie mis-spoke, we are not doing the test exactly locked rotor, we actually have scaled way back chasing a position hold stability problem. Currently I have only two of the three phase connected on my motor, and in software I have forced all current feedback to zero, as well as encoder feedback. This results in phase A being 50% duty cycle, and phased B and C being complementary; we can even stop the code and keep the bridge running to ensure that there are no pwm changes. We still see the variation in this case. Jamie's scope shot is the gate signal falling edge whilst triggering on the rising edge, it is taken on a single energized phase with current flowing in continuous conduction mode.
Can you provide any other feedback while you are waiting for those big picture scope shot(s)? We are really stuck here, that jitter in pulse width is causing problems. Is there some way to disable the dead-time in the DRV8305 so we can use just the microcontroller's timing, which is much more stable?
Hey Mark,
Apologizes for the delay, I think I've compiled your settings into the picture below, let me know if something doesn't agree.
We'll shelve the current limit issue for now and talk about your PI Loop. So if I understand you correctly, you control the input speed command to the motor using I2C. You do this by enabling the override bit which is SpeedCtrl2[7] (to enabled I2C speed control), and the write some value in the SpeedCtrl1 register and maybe use bit 0 in SpeedCtrl1 if you go fast enough.
If this is true, then, this amount is translated into a speed command percentage which is pushed to SpeedCmd[7:0]. After looking at your settings (more on this later) it eventually pushed to the the speed command buffer (spdCmdBuffer[7:0]) which is then translated to an electrical frequency in Hz (Motor Speed1 and 2). Then, the electrical frequency is then transferred to RPM using the equation RPM = 60*f_electrical/(n_pole_pairs_motor). Hopefully this gives you some insight why I don't think updating the SpdCtrl Register that quickly will be a problem.
The max speed command that should be used to control I2C is 0xFF in SpeedCtrl1 with "1" in the SpeedCtrl2[0]. This would look like 0x1FF for SpdCtrl[8:0]. Hopefully this answers your max speed you can write into the registers.
Now for you current limit problem. I noticed that you closed loop accelerate rate is rather high; this can lead to the speed command buffer changing rapidly which leads to current being surged very quickly if the new speed command much higher than the original one (something that a PI loop might do). Try lowering it 0.091 VCC/s, for example, and see if the current limit still occurs (and if it does, let's see at what level).
Let me know if this helps,
-Cole
Part Number: DRV10983
I am working on a custom designed board using the DRV10983, with an external MCU running a PI speed control loop. The motor speed is being read via I2C, run through the PI loop and the Speed Control register is updated to keep the motor speed consistent. The motor was tuned according to TI documentation and appears to be running properly. Using a Tek scope with a current probe, my peak current through a motor phase is 1.49A (peak, not RMS). While tuning my speed control loop, I have found that the DRV10983 is consistently tripping the Lock0 fault. My original setting for the HWiLimitThr register was 0x06 which should equal 2.8A. When discovering this, I increased the HWiLimitThr to 0x07 which should equal 3.2A. Much to my confusion, I found that I was actually tripping the Lock0 fault at a lower peak current threshold during operation. After finding this, I decreased the HWiLimitThr to 0x05 which should equal 2.4A, and with this lower threshold, I now see longer operation at my peak operating current than with higher HWiLimitThr values. I am still seeing Lock0 faults which is a problem, so I need some help in figuring out why I am seeing lower thresholds for higher HWiLimitThr values. Especially considering I am now where near the current trip values on my scope measurements. I was able to capture the trip point where the Lock0 fault occurred with HWiLimitThr = 0x07 and the DRV10983 was tripping when less than 1A was going through the motor phases.
Any help would be greatly appreciated,
Mark
Youssef,
VCC below 9V will tr-state driver.
What type of output stage did you use for driving low side? Are you suing Darlingtons or NPETs?
Thanks
Seil
Part Number: UC2625
Hello,
I am using the UC2625 and I cannot seem to pinpoint which block will the turn-off and turn-on threshold directly affect, and does PWR VCC and VCC have to be supplied with the same voltage?
Thank You
Youssef
Part Number: DRV8841
Hi,
I have noticed that the DRV8841 outputs have a phase jitter in the range of about 400ns and I believe it might be causing micro-stepping problems. I'm driving a 3 phase stepping motor and I need each phase to faithfully follow the input AIN and BIN PWM inputs. I can see that one of the bridges in the part has a 3us delay from the other and can compensate for that, but the jitter of each phase seems to be random on each phase. Please see attached video of two of the phase.
Some additional information:
1. PWM inputs look stable
2. Driver outputs jitter with and without load.
3. DRV8841 current controller is not being used. Vref = 3.3V and Sense resistor is 0.5R. Drive Current is 600mA - 1A
Thank you.
[View:/cfs-file/__key/communityserver-discussions-components-files/38/Motor-Pwm-Jitter.mp4:1230:0]
Part Number: DRV8307
Hello,
I am testing the BLDC motor part no. B773DA3C428D using DRV8307. Its working fine at all duty cycles above around 10%. But at Lower than 10%, it is failed to work. I am not able to understand the issue. PWM frequency was 20KHz. I also tried to increase the PWM frequency so as to check whether there is any minimum Ton required for the IC, but it still shows the same behaviour of not being able to work below 10%. Please guide me to solve this issue. We need this driver to get operated from 0% to 100% with 12-bit resolution i.e. 4096 steps(which is maximum bits available in IC).
I don't have the board in working order right now, but the gates out of the microcontroller are like this - no dead time added.
Phase AH (50% duty) ________|^^^^^^^^^|_________|^^^^^^^^^|
Phase AL (50% duty) ^^^^^^^^|_________|^^^^^^^^^|_________|
Phase BH (52% duty) ________|^^^^^^^^^^^|_______|^^^^^^^^^^^|_
Phase BL (48% duty) ^^^^^^^^|___________|^^^^^^^|___________|^
Phase CH (48% duty) __________|^^^^^^^|___________|^^^^^^^|___
Phase CL (52% duty) ^^^^^^^^^^|_______|^^^^^^^^^^^|_______|^^^
Part Number: DRV8305
I'm struggling to understand what is going with the dead time in my circuit. I understand that the DRV8305 tdrive system automatically ensures that a switch is turned off prior to turning on the opposite transistor. This is a great feature in concept; however I am concerned that the dead-time that it inserts is not consistent, and varies by 40nS between switching cycles.
I've got my processor outputting constant pwm, and when I look at the low side there is a consistent relationship between the gate commands (see second scope trace), however when I look at the actual gate commands coming out of the DRV8305, I see inconsistency. Below is a scope shot of that; Yellow trace is phase B lower switch gate. Blue trace is phase C lower switch gate. Current is flowing, but small, pwms are in a fixed state. You can see that the blue trace is going high either 40 or 80ns after the yellow trace (the trigger)
This plot below shows the same signals at the input to the chip - no variation visible.
I'm running a very low inductance motor, so when the motor is stopped, as it is in this test, the duty cycles are small. The variation that is being created by the dead-time inconsistency has a large impact on current, and causes instability. I'd like to make it go away. Is there some way to turn off dead time on the DRV8305? Then I will generate deterministic 100uS dead-time on my microcontroller. If there is not way to turn it off, what steps can I take to stabilize this effect?
Thanks
Hello everyone, i need you help!
i want to get the precision of at lest 10 mA absolute error when the current varying from 0 A to 10 A, Specially at 0 A. But most of the current sensor solutions have input voltage offset, I wonder if there any solutions ? And whether the shunt resistor current sensor or fluxgate sensor is better to choose in the case of offset voltage ?