Sign in

Not a member? | Forgot your Password?

Search compdsp

Search tips

Find us on Facebook!





Free PDF Downloads

A Quadrature Signals Tutorial: Complex, But Not Complicated

Understanding the 'Phasing Method' of Single Sideband Demodulation

Complex Digital Signal Processing in Telecommunications

Introduction to Sound Processing

C++ Tutorial

Introduction of C Programming for DSP Applications

Fixed-Point Arithmetic: An Introduction

Cascaded Integrator-Comb (CIC) Filter Introduction

Discussion Groups

FFT Spectral Analysis Software

Free Online Books

See Also

Embedded SystemsFPGA

Discussion Groups | Comp.DSP | Map controller output to PWM duty-cycle

There are 5 messages in this thread.

You are currently looking at messages 1 to .


Is this discussion worth a thumbs up?

0

Map controller output to PWM duty-cycle - Dirceu - 2010-01-12 14:02:00

Hello,
	I've a practical question regarding Digital Control Systems (specifically
Switched mode power supply) implemented on DSP chip. Since that a
controller is kind of IIR filter, I think this place is very suitable to
this question.

	In power systems, the DC-DC converter (Buck, Boost, etc..) is normally
described by a transfer function relating input - PWM duty-cycle and output
- the analog voltage. The controller (PI in my case) receives the error
signal and outputs the duty value (0 to 100%) to converter.

	Very often, I design the controller in Matlab SISOTOOL based on desired
specs like bandwidth, phase margin and settling time, resulting on a
difference equation (with numerical representation on DSP / micro as Q15 or
similar). 

	My question: Considering a controller designed properly to attain the
requirements, having coefficients bigger than one. Ex:

d(k) = d(k) + 25*e(k) - 23*e(k-1)

In order to use Q15 format, I could scale the coeffs by 1/32, as:

(1/32)*d(k) = (1/32)*d(k) + (1/32)*25*e(k) - (1/32)*23*e(k-1)

	This procedure solves the calculations. Following MACs routine,  I've
multiplicate duty "d" by 32. But, here is the heart of problem, since after
all, the control signal from a step response, shows an initial value of 25
(error e(0) = 25). What the real meaning of that. Would be an impossible
2500% duty-cycle? 

	Two  practical "solutions": (1) Do not make the final step (x 32) -
having coeffs lower than 1. (2) Saturates the control output until this
signal stay below 1. Both seems to conflicts with designed by SISOTOOL. For
me, these "artificial" scaling or "saturation", needs some interpretation
(make physical sense).

 	Of course, my design could be wrong from beginning. So, I must work in
order to get lower coeffs (maybe not fulfilling the original specs).

Please, some clarification.


Re: Map controller output to PWM duty-cycle - Tim Wescott - 2010-01-12 14:17:00

On Tue, 12 Jan 2010 13:02:10 -0600, Dirceu wrote:

> Hello,
> 	I've a practical question regarding Digital Control Systems
> 	(specifically
> Switched mode power supply) implemented on DSP chip. Since that a
> controller is kind of IIR filter, I think this place is very suitable to
> this question.
> 
> 	In power systems, the DC-DC converter (Buck, Boost, etc..) is 
normally
> described by a transfer function relating input - PWM duty-cycle and
> output - the analog voltage. The controller (PI in my case) receives the
> error signal and outputs the duty value (0 to 100%) to converter.
> 
> 	Very often, I design the controller in Matlab SISOTOOL based on 
desired
> specs like bandwidth, phase margin and settling time, resulting on a
> difference equation (with numerical representation on DSP / micro as Q15
> or similar).
> 
> 	My question: Considering a controller designed properly to attain 
the
> requirements, having coefficients bigger than one. Ex:
> 
> d(k) = d(k) + 25*e(k) - 23*e(k-1)
> 
> In order to use Q15 format, I could scale the coeffs by 1/32, as:
> 
> (1/32)*d(k) = (1/32)*d(k) + (1/32)*25*e(k) - (1/32)*23*e(k-1)
> 
> 	This procedure solves the calculations. Following MACs routine,  
I've
> multiplicate duty "d" by 32. But, here is the heart of problem, since
> after all, the control signal from a step response, shows an initial
> value of 25 (error e(0) = 25). What the real meaning of that. Would be
> an impossible 2500% duty-cycle?
> 
> 	Two  practical "solutions": (1) Do not make the final step (x 32) 
-
> having coeffs lower than 1. (2) Saturates the control output until this
> signal stay below 1. Both seems to conflicts with designed by SISOTOOL.
> For me, these "artificial" scaling or "saturation", needs some
> interpretation (make physical sense).
> 
>  	Of course, my design could be wrong from beginning. So, I must 
work in
> order to get lower coeffs (maybe not fulfilling the original specs).
> 
> Please, some clarification.

The SISOTOOL operates in the egghead math world, where all systems are 
linear and physical limitations like overflow, >100% duty cycles, and 
semiconductors letting all the magic smoke out simply don't exist.

Your first cut at this is to simply saturate the output: if d(k)/32 > 
1/32, then let d(k) = 1 (and if d(k)/32 < 0, let d(k) = 0).  This has the 
physical meaning that when your controller "asks" for more duty cycle 
range than is possible, the following code trims the request to what can 
be done.

If you have an integrator in your system this will immediately cause you 
problems -- when you have an integrating controller followed by a 
saturation stage you can have a phenomenon known as 'integrator windup'.  
It's well known, and there are a number of different ways to implement 
it, each one with it's advantages and disadvantages.  There is no global 
optimum, because as soon as you acknowledge that your duty cycle is 
limited you have forked yourself into a nonlinear control problem, where 
optimal solutions are hard to find and change like smoke as your 
requirements change.

I want to point out that you will probably do much better if you take 
Matlab's output and turn the difference equation into a PID format, 
separately treating the proportional, integral and difference terms.  
This page will lead you to an article: http://www.wescottdesign.com/
articles/Sampling/pidwophd.html.  That article is pretty basic, but it 
does show a canonical bit of PID code, as well as presenting the World's 
Most Basic Integrator Anti-Windup algorithm.

You should probably also get my book, if you're willing to do a bit of 
math: http://www.wescottdesign.com/actfes/actfes.html.  If the Powell's 
link on that page (which I really need to update) doesn't bring you joy, 
search for the title on Amazon.  There's a lot more background and detail 
in there.

-- 
www.wescottdesign.com


Re: Map controller output to PWM duty-cycle - Vladimir Vassilevsky - 2010-01-12 14:28:00

Dirceu wrote:
> Hello,
> 	I've a practical question regarding Digital Control Systems (specifically
> Switched mode power supply) implemented on DSP chip.

DSP controlled SMPS can work very nicely indeed; especially if you 
employ optimal control algorithms rather then the classic linear control.

> Since that a
> controller is kind of IIR filter, I think this place is very suitable to
> this question.
> 
> 	In power systems, the DC-DC converter (Buck, Boost, etc..) is normally
> described by a transfer function relating input - PWM duty-cycle and output
> - the analog voltage. The controller (PI in my case) receives the error
> signal and outputs the duty value (0 to 100%) to converter.
> 
> 	Very often, I design the controller in Matlab SISOTOOL based on desired
> specs like bandwidth, phase margin and settling time, resulting on a
> difference equation (with numerical representation on DSP / micro as Q15 or
> similar). 
> 
> 	My question: Considering a controller designed properly to attain the
> requirements, having coefficients bigger than one. Ex:
> 
> d(k) = d(k) + 25*e(k) - 23*e(k-1)

Your integrator d(k) is truncated to PWM accuracy. Not good.

> In order to use Q15 format, I could scale the coeffs by 1/32, as:
> 
> (1/32)*d(k) = (1/32)*d(k) + (1/32)*25*e(k) - (1/32)*23*e(k-1)
> 
> 	This procedure solves the calculations. Following MACs routine,  I've
> multiplicate duty "d" by 32. But, here is the heart of problem, since after
> all, the control signal from a step response, shows an initial value of 25
> (error e(0) = 25). What the real meaning of that. Would be an impossible
> 2500% duty-cycle? 

Unreasonable requirements.

> Two  practical "solutions": (1) Do not make the final step (x 32) -
> having coeffs lower than 1. (2) Saturates the control output until this
> signal stay below 1. Both seems to conflicts with designed by SISOTOOL. For
> me, these "artificial" scaling or "saturation", needs some interpretation
> (make physical sense).
> 
> Of course, my design could be wrong from beginning. So, I must work in
> order to get lower coeffs (maybe not fulfilling the original specs).
> 
> Please, some clarification.

Startup, shutdown, overload and no-load are special conditions. The 
general control function won't work for those cases. You should address 
those modes of operation by separate branches in your algorithm.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com


Re: Map controller output to PWM duty-cycle - Tim Wescott - 2010-01-12 15:22:00

On Tue, 12 Jan 2010 13:28:53 -0600, Vladimir Vassilevsky wrote:

> Dirceu wrote:
>> Hello,
>> 	I've a practical question regarding Digital Control Systems
>> 	(specifically
>> Switched mode power supply) implemented on DSP chip.
> 
> DSP controlled SMPS can work very nicely indeed; especially if you
> employ optimal control algorithms rather then the classic linear
> control.
> 
>> Since that a
>> controller is kind of IIR filter, I think this place is very suitable
>> to this question.
>> 
>> 	In power systems, the DC-DC converter (Buck, Boost, etc..) is 
normally
>> described by a transfer function relating input - PWM duty-cycle and
>> output - the analog voltage. The controller (PI in my case) receives
>> the error signal and outputs the duty value (0 to 100%) to converter.
>> 
>> 	Very often, I design the controller in Matlab SISOTOOL based on
>> 	desired
>> specs like bandwidth, phase margin and settling time, resulting on a
>> difference equation (with numerical representation on DSP / micro as
>> Q15 or similar).
>> 
>> 	My question: Considering a controller designed properly to attain 
the
>> requirements, having coefficients bigger than one. Ex:
>> 
>> d(k) = d(k) + 25*e(k) - 23*e(k-1)
> 
> Your integrator d(k) is truncated to PWM accuracy. Not good.
> 
>> In order to use Q15 format, I could scale the coeffs by 1/32, as:
>> 
>> (1/32)*d(k) = (1/32)*d(k) + (1/32)*25*e(k) - (1/32)*23*e(k-1)
>> 
>> 	This procedure solves the calculations. Following MACs routine,  
I've
>> multiplicate duty "d" by 32. But, here is the heart of problem, since
>> after all, the control signal from a step response, shows an initial
>> value of 25 (error e(0) = 25). What the real meaning of that. Would be
>> an impossible 2500% duty-cycle?
> 
> Unreasonable requirements.
> 
>> Two  practical "solutions": (1) Do not make the final step (x 32) -
>> having coeffs lower than 1. (2) Saturates the control output until this
>> signal stay below 1. Both seems to conflicts with designed by SISOTOOL.
>> For me, these "artificial" scaling or "saturation", needs some
>> interpretation (make physical sense).
>> 
>> Of course, my design could be wrong from beginning. So, I must work in
>> order to get lower coeffs (maybe not fulfilling the original specs).
>> 
>> Please, some clarification.
> 
> Startup, shutdown, overload and no-load are special conditions. The
> general control function won't work for those cases. You should address
> those modes of operation by separate branches in your algorithm.

Vladimir and I think differently.  I don't like 'modal' control loops 
(i.e. a collection of regular loops that are switched in and out by an 
executive that inevitably gets confused about what mode its in).  If I 
can, I much prefer to implement modes the way analog circuits often do -- 
like current limiting, which is more or less two control commands, and 
the smallest one wins.

This gives you a controller with built-in nonlinearities to automatically 
respond correctly to the situation rather than mistaking the mode it's 
in.  Also, when you start thinking like this, you'll often find that 
things appear to be dissimilar (like startup and overload) can be folded 
into one mode (i.e. current limited).

-- 
www.wescottdesign.com


Re: Map controller output to PWM duty-cycle - steveu - 2010-01-12 20:45:00

>On Tue, 12 Jan 2010 13:28:53 -0600, Vladimir Vassilevsky wrote:
>
>> Dirceu wrote:
>>> Hello,
>>> 	I've a practical question regarding Digital Control Systems
>>> 	(specifically
>>> Switched mode power supply) implemented on DSP chip.
>> 
>> DSP controlled SMPS can work very nicely indeed; especially if you
>> employ optimal control algorithms rather then the classic linear
>> control.
>> 
>>> Since that a
>>> controller is kind of IIR filter, I think this place is very suitable
>>> to this question.
>>> 
>>> 	In power systems, the DC-DC converter (Buck, Boost, etc..) is 
>normally
>>> described by a transfer function relating input - PWM duty-cycle and
>>> output - the analog voltage. The controller (PI in my case) receives
>>> the error signal and outputs the duty value (0 to 100%) to converter.
>>> 
>>> 	Very often, I design the controller in Matlab SISOTOOL based on
>>> 	desired
>>> specs like bandwidth, phase margin and settling time, resulting on a
>>> difference equation (with numerical representation on DSP / micro as
>>> Q15 or similar).
>>> 
>>> 	My question: Considering a controller designed properly to attain 
>the
>>> requirements, having coefficients bigger than one. Ex:
>>> 
>>> d(k) = d(k) + 25*e(k) - 23*e(k-1)
>> 
>> Your integrator d(k) is truncated to PWM accuracy. Not good.
>> 
>>> In order to use Q15 format, I could scale the coeffs by 1/32, as:
>>> 
>>> (1/32)*d(k) = (1/32)*d(k) + (1/32)*25*e(k) - (1/32)*23*e(k-1)
>>> 
>>> 	This procedure solves the calculations. Following MACs routine,  
>I've
>>> multiplicate duty "d" by 32. But, here is the heart of problem, since
>>> after all, the control signal from a step response, shows an initial
>>> value of 25 (error e(0) = 25). What the real meaning of that. Would
be
>>> an impossible 2500% duty-cycle?
>> 
>> Unreasonable requirements.
>> 
>>> Two  practical "solutions": (1) Do not make the final step (x 32) -
>>> having coeffs lower than 1. (2) Saturates the control output until
this
>>> signal stay below 1. Both seems to conflicts with designed by
SISOTOOL.
>>> For me, these "artificial" scaling or "saturation", needs some
>>> interpretation (make physical sense).
>>> 
>>> Of course, my design could be wrong from beginning. So, I must work
in
>>> order to get lower coeffs (maybe not fulfilling the original specs).
>>> 
>>> Please, some clarification.
>> 
>> Startup, shutdown, overload and no-load are special conditions. The
>> general control function won't work for those cases. You should
address
>> those modes of operation by separate branches in your algorithm.
>
>Vladimir and I think differently.  I don't like 'modal' control loops 
>(i.e. a collection of regular loops that are switched in and out by an 
>executive that inevitably gets confused about what mode its in).  If I 
>can, I much prefer to implement modes the way analog circuits often do --

>like current limiting, which is more or less two control commands, and 
>the smallest one wins.

The main loop goes completely wacky when the analogue plant moves outside
the area it was designed for. If you don't use a modal approach it takes
time for the controller to come back into range when conditions recover. I
think the modal approach has he potential to recover in a snappier way.
YMMV.

>This gives you a controller with built-in nonlinearities to automatically

>respond correctly to the situation rather than mistaking the mode it's 
>in.  Also, when you start thinking like this, you'll often find that 
>things appear to be dissimilar (like startup and overload) can be folded

>into one mode (i.e. current limited).

That depends on the exact architecture of the analogue plant. Right now
few people use digital control for simple buck converters. It is mostly
being applied to resonant techniques (its currently more expensive, so it
goes into the more expensive supplies). Things don't seem to fold so well
with all the bells and whistles it takes to make a 96% efficient
converter.

Steve