use comparator in Cycle-by-cycle current control loop

[lowpowermcu]

Posted on December 19, 2012 at 15:08

Hi all,

In comparator section of reference manual of stm32f30x devices. It is mentioned:

''Cycle-by-cycle current control loop when combined with the DAC and a PWM output

from a timer''.

What does it mean? Is there some explanations on the web?

Herzlich

 

MCU L�fter,

#dac-comp

[jj2]

Posted on December 19, 2012 at 16:47

''Cycle-by-cycle'' current limiting is an effective technique when employing PWM - especially in BLDC motor control.  With PWM @ 20KHz - and PWM generators set to ''center'' rather than edge - the ''live'' motor current can be measured and then compared against torque or current limiting.  (it's helpful if the PWM Generator automatically ''triggers'' the ADC conversion)

When the monitored motor current exceeds our pre-set value - we disable the PWM outputs for that cycle.  50uS later (@ 20KHz PWM rates) we check the current again - if ok the PWM output is re-enabled. 

This method is especially effective against transient over-currents - many/most of which are self-clearing if the PWM is killed for a cycle or several.  Should the over-current persist beyond a reasonable number of PWM Cycles - we shut down the motor and provide an over-current detection report on local (and remote) displays.

[frankmeyer9]

Posted on December 19, 2012 at 17:08

More generally, ''cycle by cycle'' refers to controlling the current in a closed loop, based on measurements in the same PWM cycle. It is used for other PWM controlled loops, too, not only motor control. DC/DC converters and LED converters (for lighting) use PWM frequencies of up to 100 ... 200 kHz.

That is a challenge for most controllers, as it results in a 5 .. 10us overall cycle time.

[jj2]

Posted on December 19, 2012 at 21:22

Indeed you are correct in properly identifying the broader usage of, ''Cycle by cycle.''  And modern DC-DC converters employ this technique well - suspect so well that it would prove wasteful to burden (and task limit) an MCU when a dedicated IC can well solve.

At the lower frequencies encountered in the motor-control and certain other control fields - an MCU with PWM generators, analog comparator, and enhanced PWM Fault Handling (perhaps a slelectable/dedicated pin) is well capable of adding, ''Cycle by cycle'' to its bag of tricks...

[lowpowermcu]

Posted on December 20, 2012 at 10:26

Hi sprague,

Thankk you for your explanation but what could be the role of the DAC?

Is there some application notes on stm32 which explains this  (or even from copetitors)?

[frankmeyer9]

Posted on December 20, 2012 at 10:56

The DAC is often used to set the threshold for a comparator.

And this comparator, in turn, compares the measured current (i.e. voltage drop over a shunt) with this reference voltage. The comparator output turns the switch (i.e. mostly a MOSFET) on or off.

This way, the current and thus the amount of power transferred to the output is controlled.

[jj2]

Posted on December 20, 2012 at 20:54

As poster fm states - the DAC output could be routed to one of the MCU's analog comparator inputs.  In our case - a small pot proves simpler.  (and provides instant visual feedback of setting - via the pot's slot)  Believe the DAC mention was unnecessary - it is not a vital part for ''Cycle by cycle.'' 

We have a far different approach when it comes to handling/managing the MCU's comparator output - we route this directly to the PWM Fault Handler pin - and this disables PWM output from all active (and so programmed) PWM Generators when the comparator transitions from its ''safe'' zone.   In the case of motor drive - the analog comparator would never tie directly to the power FET stage - separate gate drivers receive the MCU's PWM signals and these gate drivers properly excite both the high and low side power FETs.

[frankmeyer9]

Posted on December 20, 2012 at 21:30

In dimmable LED converters, the DAC value (and thus the comparator reference) is tied to the dim value. The DAC resolution is therefore a crucial parameter for resolution, at least in this setup.

Albeit dimming down to 0.1 percent is somehow ridiculous, it is still a sales argument  ...

[jj2]

Posted on December 21, 2012 at 02:54

Interesting to note that you properly ''generalized'' my 1st response to, ''Cycle by cycle poster'' - and that now you've steered to Led (specialized) while I persist in the area of motors and actuators.  (also specialized but perhaps more in the MCU perspective)

The DAC does allow ''dynamic'' (i.e. software controlled) adjustment of the, ''Cycle by cycle'' current-limiting set-point - but does so at the cost of added MCU software to both condition and adjust the DAC - and then ''send'' its setting to some remote or local display.  Pot - by contrast - is far simpler - announces its setting visually - but has no dynamic adjustment capability.

[Nickname12657_O]

Posted on December 21, 2012 at 10:52

Hi all,

To enhance this valuable disussion and in response to the question regarding application notes on stm32 which explains DAC role, the following ANs may be interesting:

http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/DM00055171.pdf

http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00280599.pdf

Cheers,

STOne-32

[frankmeyer9]

Posted on December 21, 2012 at 11:06

Surely you are right.

I just wanted to point out another usage of the DAC in control loops.

In commercial LED converters, there are usually no potentiometer. Instead, dimming by remote command (usually DALI) is a requirement.

And yes, it adds costs to the MCU.

But that is a rather specific topic ...