Control loop precision

Hi everyone,

I have a current control loop based on a PI controller, a PWM and a
half-bridge to drive current through a phase of a BLDC. The current is
measured via an OPAMP and ADC and fed back to the PI.

I know what is the precision of my actuator (PWM + Half-bridge), as well
as my OPAMP and ADC, but I'm having troubles in understanding what will
be the overall current precision at the end and how the PI coefficient
may impact on this precision.

Not only I have to calculate the output precision, but eventually I
should make sure that any single block of my control loop is correctly
sized in order to achieve my target without the need to over specify any
one in particular.

Any comment/suggestion is appreciated.

Al

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On Fri, 03 Jun 2016 17:06:39 +0200, alb wrote:

> Hi everyone,
> 
> I have a current control loop based on a PI controller, a PWM and a
> half-bridge to drive current through a phase of a BLDC. The current is
> measured via an OPAMP and ADC and fed back to the PI.
> 
> I know what is the precision of my actuator (PWM + Half-bridge), as well
> as my OPAMP and ADC, but I'm having troubles in understanding what will
> be the overall current precision at the end and how the PI coefficient
> may impact on this precision.
> 
> Not only I have to calculate the output precision, but eventually I
> should make sure that any single block of my control loop is correctly
> sized in order to achieve my target without the need to over specify any
> one in particular.
> 
> Any comment/suggestion is appreciated.

I'm assuming that the PI controller is controlling the PWM.

This is complicated.  The best quick estimate ("quick" is a relative 
term, here) is to make a block diagram of the whole system, with noise 
injection at each point where you can identify an error.  Turn the known 
error sources into noise of the appropriate type (i.e., white, DC, 
synchronous with the BLDC, or worst-case).  Then add them up.

For quantization noise, if you really want to be honest with yourself, 
you should find the system response to the noise over frequency, pick the 
worst-case frequency, and put all of the quantization noise there.  
That's because that worst-case frequency is often where the thing will be 
oscillating around the quantization, unless there's enough other noise in 
the system to scramble it.

It's lots of icky-picky work, but as long as you keep careful track of 
dimensions (i.e., put signals into "volts", "amps" and "counts", and 
express gains as "volts/count", "counts/volt", "volts/amp", etc.), then 
you should have a straight road to getting an answer.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

Hi Tim,

On 03.06.2016 18:35, Tim Wescott wrote:
>> I have a current control loop based on a PI controller, a PWM and a
>> half-bridge to drive current through a phase of a BLDC. The current is
>> measured via an OPAMP and ADC and fed back to the PI.
[]
>> Not only I have to calculate the output precision, but eventually I
>> should make sure that any single block of my control loop is correctly
>> sized in order to achieve my target without the need to over specify any
>> one in particular.
[]
> I'm assuming that the PI controller is controlling the PWM.

correct assumption and the PI output is over a 12 bit, while the PWM is
9 bit due to PWM carrier and main clock onboard (f_pwm = 88 kHz, f_clk =
40 MHz => only 450 periods available, minus some dead zone at the
extremities of the full ranges due to H-bridge MOS transition time).
Therefore whatever kind of precision I have at the level of the PI it is
screwed up by a factor 4 in the PWM and I'm not sure I can do anything
about it.

> This is complicated.  The best quick estimate ("quick" is a relative 
> term, here) is to make a block diagram of the whole system, with noise 
> injection at each point where you can identify an error.  Turn the known 
> error sources into noise of the appropriate type (i.e., white, DC, 
> synchronous with the BLDC, or worst-case).  Then add them up.

Why adding them up? If the sources of noise can be demonstrated
independent, couldn't I simply square root the squared sum of them? It
is certainly less accurate since it's based on the assumption that noise
distributions are normal but is certainly more likely than the worst
case scenario of the total sum.

> For quantization noise, if you really want to be honest with yourself, 
> you should find the system response to the noise over frequency, pick the 
> worst-case frequency, and put all of the quantization noise there.  
> That's because that worst-case frequency is often where the thing will be 
> oscillating around the quantization, unless there's enough other noise in 
> the system to scramble it.

We have the possibility to add some dither, but I'm not sure yet how to
use it. But back to basis, you're suggesting to inject a noise spectrum
at each entry point and then measure the noise spectrum at the output
since we are assuming an LTI system, right? But shouldn't we add power
density?

Is the control loop frequency response going to cut off some of the noise?

> It's lots of icky-picky work, but as long as you keep careful track of 
> dimensions (i.e., put signals into "volts", "amps" and "counts", and 
> express gains as "volts/count", "counts/volt", "volts/amp", etc.), then 
> you should have a straight road to getting an answer.

That is correct and each of these conversions in the digital domain will
include an error due to the operation precision I suppose. I believe I
may need to increase the PI data width in order to avoid overflow in the
multiplication.

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On Friday, June 3, 2016 at 10:38:02 AM UTC-7, alb wrote:
> Hi Tim,
> 
> On 03.06.2016 18:35, Tim Wescott wrote:
> >> I have a current control loop based on a PI controller, a PWM and a
> >> half-bridge to drive current through a phase of a BLDC. The current is
> >> measured via an OPAMP and ADC and fed back to the PI.
> []
> >> Not only I have to calculate the output precision, but eventually I
> >> should make sure that any single block of my control loop is correctly
> >> sized in order to achieve my target without the need to over specify any
> >> one in particular.
> []
> > I'm assuming that the PI controller is controlling the PWM.
> 
> correct assumption and the PI output is over a 12 bit, while the PWM is
> 9 bit due to PWM carrier and main clock onboard (f_pwm = 88 kHz, f_clk =
> 40 MHz => only 450 periods available, minus some dead zone at the
> extremities of the full ranges due to H-bridge MOS transition time).
> Therefore whatever kind of precision I have at the level of the PI it is
> screwed up by a factor 4 in the PWM and I'm not sure I can do anything
> about it.
> 

Then your overall precision is no better than 9 bits.  Perhaps you need a faster CPU.

On Fri, 03 Jun 2016 19:37:57 +0200, alb wrote:

> Hi Tim,
> 
> On 03.06.2016 18:35, Tim Wescott wrote:
>>> I have a current control loop based on a PI controller, a PWM and a
>>> half-bridge to drive current through a phase of a BLDC. The current is
>>> measured via an OPAMP and ADC and fed back to the PI.
> []
>>> Not only I have to calculate the output precision, but eventually I
>>> should make sure that any single block of my control loop is correctly
>>> sized in order to achieve my target without the need to over specify
>>> any one in particular.
> []
>> I'm assuming that the PI controller is controlling the PWM.
> 
> correct assumption and the PI output is over a 12 bit, while the PWM is
> 9 bit due to PWM carrier and main clock onboard (f_pwm = 88 kHz, f_clk =
> 40 MHz => only 450 periods available, minus some dead zone at the
> extremities of the full ranges due to H-bridge MOS transition time).
> Therefore whatever kind of precision I have at the level of the PI it is
> screwed up by a factor 4 in the PWM and I'm not sure I can do anything
> about it.
> 
>> This is complicated.  The best quick estimate ("quick" is a relative
>> term, here) is to make a block diagram of the whole system, with noise
>> injection at each point where you can identify an error.  Turn the
>> known error sources into noise of the appropriate type (i.e., white,
>> DC, synchronous with the BLDC, or worst-case).  Then add them up.
> 
> Why adding them up? If the sources of noise can be demonstrated
> independent, couldn't I simply square root the squared sum of them? It
> is certainly less accurate since it's based on the assumption that noise
> distributions are normal but is certainly more likely than the worst
> case scenario of the total sum.
> 
>> For quantization noise, if you really want to be honest with yourself,
>> you should find the system response to the noise over frequency, pick
>> the worst-case frequency, and put all of the quantization noise there.
>> That's because that worst-case frequency is often where the thing will
>> be oscillating around the quantization, unless there's enough other
>> noise in the system to scramble it.
> 
> We have the possibility to add some dither, but I'm not sure yet how to
> use it.

Generally in systems like this the noise level adds dither, free of 
charge.

> But back to basis, you're suggesting to inject a noise spectrum
> at each entry point and then measure the noise spectrum at the output
> since we are assuming an LTI system, right? But shouldn't we add power
> density?

I'm suggesting that you do this on paper, and calculate the noise 
spectrum at the output.

To the extent that you can count on the noise being independent and 
random, yes, you should add it in the mean-square sense.  It's not 
necessary to add power densities unless you want a predicted output 
spectrum.

> Is the control loop frequency response going to cut off some of the
> noise?

More like it'll enhance it -- but the plant response should cut off some 
high-frequency noise.

>> It's lots of icky-picky work, but as long as you keep careful track of
>> dimensions (i.e., put signals into "volts", "amps" and "counts", and
>> express gains as "volts/count", "counts/volt", "volts/amp", etc.), then
>> you should have a straight road to getting an answer.
> 
> That is correct and each of these conversions in the digital domain will
> include an error due to the operation precision I suppose. I believe I
> may need to increase the PI data width in order to avoid overflow in the
> multiplication.

You need to do your calculations, first.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

On Fri, 03 Jun 2016 13:18:37 -0700, edward.ming.lee wrote:

> On Friday, June 3, 2016 at 10:38:02 AM UTC-7, alb wrote:
>> Hi Tim,
>> 
>> On 03.06.2016 18:35, Tim Wescott wrote:
>> >> I have a current control loop based on a PI controller, a PWM and a
>> >> half-bridge to drive current through a phase of a BLDC. The current
>> >> is measured via an OPAMP and ADC and fed back to the PI.
>> []
>> >> Not only I have to calculate the output precision, but eventually I
>> >> should make sure that any single block of my control loop is
>> >> correctly sized in order to achieve my target without the need to
>> >> over specify any one in particular.
>> []
>> > I'm assuming that the PI controller is controlling the PWM.
>> 
>> correct assumption and the PI output is over a 12 bit, while the PWM is
>> 9 bit due to PWM carrier and main clock onboard (f_pwm = 88 kHz, f_clk
>> =
>> 40 MHz => only 450 periods available, minus some dead zone at the
>> extremities of the full ranges due to H-bridge MOS transition time).
>> Therefore whatever kind of precision I have at the level of the PI it
>> is screwed up by a factor 4 in the PWM and I'm not sure I can do
>> anything about it.
>> 
>> 
> Then your overall precision is no better than 9 bits.  Perhaps you need
> a faster CPU.

Typically the precision of the drive that's applied to a motor can be far 
less than what you need at the motor shaft.  So I wouldn't hold to this 
rule of thumb too tightly.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

On Friday, June 3, 2016 at 1:34:03 PM UTC-7, Tim Wescott wrote:
> On Fri, 03 Jun 2016 13:18:37 -0700, edward.ming.lee wrote:
> 
> > On Friday, June 3, 2016 at 10:38:02 AM UTC-7, alb wrote:
> >> Hi Tim,
> >> 
> >> On 03.06.2016 18:35, Tim Wescott wrote:
> >> >> I have a current control loop based on a PI controller, a PWM and a
> >> >> half-bridge to drive current through a phase of a BLDC. The current
> >> >> is measured via an OPAMP and ADC and fed back to the PI.
> >> []
> >> >> Not only I have to calculate the output precision, but eventually I
> >> >> should make sure that any single block of my control loop is
> >> >> correctly sized in order to achieve my target without the need to
> >> >> over specify any one in particular.
> >> []
> >> > I'm assuming that the PI controller is controlling the PWM.
> >> 
> >> correct assumption and the PI output is over a 12 bit, while the PWM is
> >> 9 bit due to PWM carrier and main clock onboard (f_pwm = 88 kHz, f_clk
> >> =
> >> 40 MHz => only 450 periods available, minus some dead zone at the
> >> extremities of the full ranges due to H-bridge MOS transition time).
> >> Therefore whatever kind of precision I have at the level of the PI it
> >> is screwed up by a factor 4 in the PWM and I'm not sure I can do
> >> anything about it.
> >> 
> >> 
> > Then your overall precision is no better than 9 bits.  Perhaps you need
> > a faster CPU.
> 
> Typically the precision of the drive that's applied to a motor can be far 
> less than what you need at the motor shaft.  So I wouldn't hold to this 
> rule of thumb too tightly.

Yes, i know.  The current precision (which he asked) is 9 bits, but the speed precision (which people are interested in) could be far less.  The current to speed ratio can also depend on age.  However, higher current precision will certainly give better speed precision.

On 6/3/16 4:18 PM, edward.ming.lee@gmail.com wrote:
> On Friday, June 3, 2016 at 10:38:02 AM UTC-7, alb wrote:
>> Hi Tim,
>>
>> On 03.06.2016 18:35, Tim Wescott wrote:
>>>> I have a current control loop based on a PI controller, a PWM and a
>>>> half-bridge to drive current through a phase of a BLDC. The current is
>>>> measured via an OPAMP and ADC and fed back to the PI.
>> []
>>>> Not only I have to calculate the output precision, but eventually I
>>>> should make sure that any single block of my control loop is correctly
>>>> sized in order to achieve my target without the need to over specify any
>>>> one in particular.
>> []
>>> I'm assuming that the PI controller is controlling the PWM.
>>
>> correct assumption and the PI output is over a 12 bit, while the PWM is
>> 9 bit due to PWM carrier and main clock onboard (f_pwm = 88 kHz, f_clk =
>> 40 MHz => only 450 periods available, minus some dead zone at the
>> extremities of the full ranges due to H-bridge MOS transition time).
>> Therefore whatever kind of precision I have at the level of the PI it is
>> screwed up by a factor 4 in the PWM and I'm not sure I can do anything
>> about it.
>>
>
> Then your overall precision is no better than 9 bits.  Perhaps you need a faster CPU.
>

Not necessarily. If the bandwidth of the motor is significantly lower 
than the PWM frequency (which it almost certainly is), then you can get 
some more bits by dithering the PWM value. After all, isn't the basis of 
PWM using a ONE bit signal to generate a much higher number of states. 
It helps to be smart in how you do the dithering, to keep the frequency 
component of the dither high.

On Fri, 03 Jun 2016 19:18:15 -0400, Richard Damon wrote:

> On 6/3/16 4:18 PM, edward.ming.lee@gmail.com wrote:
>> On Friday, June 3, 2016 at 10:38:02 AM UTC-7, alb wrote:
>>> Hi Tim,
>>>
>>> On 03.06.2016 18:35, Tim Wescott wrote:
>>>>> I have a current control loop based on a PI controller, a PWM and a
>>>>> half-bridge to drive current through a phase of a BLDC. The current
>>>>> is measured via an OPAMP and ADC and fed back to the PI.
>>> []
>>>>> Not only I have to calculate the output precision, but eventually I
>>>>> should make sure that any single block of my control loop is
>>>>> correctly sized in order to achieve my target without the need to
>>>>> over specify any one in particular.
>>> []
>>>> I'm assuming that the PI controller is controlling the PWM.
>>>
>>> correct assumption and the PI output is over a 12 bit, while the PWM
>>> is 9 bit due to PWM carrier and main clock onboard (f_pwm = 88 kHz,
>>> f_clk =
>>> 40 MHz => only 450 periods available, minus some dead zone at the
>>> extremities of the full ranges due to H-bridge MOS transition time).
>>> Therefore whatever kind of precision I have at the level of the PI it
>>> is screwed up by a factor 4 in the PWM and I'm not sure I can do
>>> anything about it.
>>>
>>>
>> Then your overall precision is no better than 9 bits.  Perhaps you need
>> a faster CPU.
>>
>>
> Not necessarily. If the bandwidth of the motor is significantly lower
> than the PWM frequency (which it almost certainly is), then you can get
> some more bits by dithering the PWM value. After all, isn't the basis of
> PWM using a ONE bit signal to generate a much higher number of states.
> It helps to be smart in how you do the dithering, to keep the frequency
> component of the dither high.

Unless there's sufficient noise in the system, in which case you get 
dither for free.

I've dithered PWM signals before; it works quite well.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

Den lørdag den 4. juni 2016 kl. 01.18.48 UTC+2 skrev Richard Damon:
> On 6/3/16 4:18 PM, edward.ming.lee@gmail.com wrote:
> > On Friday, June 3, 2016 at 10:38:02 AM UTC-7, alb wrote:
> >> Hi Tim,
> >>
> >> On 03.06.2016 18:35, Tim Wescott wrote:
> >>>> I have a current control loop based on a PI controller, a PWM and a
> >>>> half-bridge to drive current through a phase of a BLDC. The current is
> >>>> measured via an OPAMP and ADC and fed back to the PI.
> >> []
> >>>> Not only I have to calculate the output precision, but eventually I
> >>>> should make sure that any single block of my control loop is correctly
> >>>> sized in order to achieve my target without the need to over specify any
> >>>> one in particular.
> >> []
> >>> I'm assuming that the PI controller is controlling the PWM.
> >>
> >> correct assumption and the PI output is over a 12 bit, while the PWM is
> >> 9 bit due to PWM carrier and main clock onboard (f_pwm = 88 kHz, f_clk =
> >> 40 MHz => only 450 periods available, minus some dead zone at the
> >> extremities of the full ranges due to H-bridge MOS transition time).
> >> Therefore whatever kind of precision I have at the level of the PI it is
> >> screwed up by a factor 4 in the PWM and I'm not sure I can do anything
> >> about it.
> >>
> >
> > Then your overall precision is no better than 9 bits.  Perhaps you need a faster CPU.
> >
> 
> Not necessarily. If the bandwidth of the motor is significantly lower 
> than the PWM frequency (which it almost certainly is), then you can get 
> some more bits by dithering the PWM value. After all, isn't the basis of 
> PWM using a ONE bit signal to generate a much higher number of states. 
> It helps to be smart in how you do the dithering, to keep the frequency 
> component of the dither high.

one way of doing it would be to use delta sigma modulation to noise shape 
the quantization to 9 bit pwm

-Lasse