This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DRV8412: Current Limit, Parallel Operation

Part Number: DRV8412

The Datasheet seems to state that if one of the circuits current-limit is exceeded, you can drive two circuits in parallel...
DS section 9.4.5 seems to state you would need 30~100nH inductance on each output in this case.
Could you provide more info on how to calculate the required inductance?

 This driver IC when operating in Parallel, doesn't have an active current share; thus it seems like the Inductor's inductive reactance causes a current loop, and you multiply by this.
Is this understanding correct?

(I am so sorry if this translation is bad...there are some terms I am not familiar with)

Here, assuming there is some starting current in the motor during the tr/tf: 14ns time-frame listed in the DS,
the 30~100nH inductive reactance is used to help hold this back, but if so, then the calculated inductive reactance seems hard to estimate from the Driver IC side of the equation, and we're having a hard time coming up with a value to use...

Summary: How to properly calculate the required inductance on the outputs when using outputs in parallel for current sharing?
Is what I believe my customer is trying to ask.

  • Darren,

    There is an equation in the datasheet to calculate this on the bottom of page 13.  The concern is shoot-thru when one channel turns on before the other does that would cause a high-current condition between power and GND.  The inductance between the parallel connected channels limits the current during this small period of time and ensures that an OCP condition will not happen.

    Regards,

    Ryan

  • Hi Ryan,

    That was really helpful. I reviewed the info/DS and discussed with my customer. 

    It seems they really want to use the device like as shown in Figure 8, where one driver controls two DC Motors.
    The issue is, the starting current for the motors is ~6.6A, 10% higher than the 6A limit.
    However, this peak current is only flowing for 10~100[ms]

    After, even over full load, the motor's only consume <1[A] to keep spinning.

    Given the above, should it be possible to have a 6.6A Peak current for this short length of time, for both motors at the same time?

    If not, it seems like it should be possible to add a series inductor like explained on p13, to limit di/dT so the motor starting current is under 6A, at the expense of a slower time for the motor to reach max RPM.

    Would you agree this is a viable option...? Or should 6.6A on both channels like in Figure 8 be acceptable for <100ms, at motor start only?

  • Darren,

    The 6A limit is a suggestion based on potential thermal limiting.  This would have to be tested in customer system to see if the device goes into thermal protection.  That is the only concern with exceeding this limit.

    Another way to limit this is to use the CBC (cycle-by-cycle) current limitation.  See datasheet.  This will limit these peaks on startup.  As you mentioned, motor will start slower, but current will be limited to avoid any thermal concerns.

    Regards,

    Ryan

  • Hi Ryan,

    Quick confirmation.

    No.

    Param

    Motor Value

    Unit

    1

    PVDD

    24

    [V]

    2

    Ipeak

    6.6

    [A]

    3

    Iave

    0.9

    [A]

    4

    Toc_delay

    250

    [ns]

    When using the above values, the calculated series inductance comes out to 1.05uH.

    1) The Datasheet recommends 30nH ~ 100nH...is this 1uH inductance (an order of magnitude larger) a viable result?

    2) What is Toc_delay? The DS equation for this inductance uses 250ns; so is this the "Ioct" parameter in the Electrical Characterisitics section?

  • Darren,

    1)  Please direct me to the page where 30-100nH is recommended.  I see no issue with 1uH.  

    2)  Yes, Toc_delay = Ioct in spec table.  

    Regards,

    Ryan

  • Hi Ryan,

    1) It is in section 9.4.5 (discussing Parallel Operation)

    2) Thanks

  • Darren,

    Got it...well, more is better.  Not sure why we put an upper bound on that.

    Regards,

    Ryan