Hi folks,

My application adjusts a voltage while monitoring and recording the
adjustment. My plan is to use one pin to generate a PWM control signal
into a driver transistor and use another pin-pair to monitor the
output voltage. Recording the PWM value will tell the offset of the
original signal. Right now, I'm looking at using three pins: (1) PWM
output, (2) ADC input, and (3) ADC ground. This looks fairly straight
forward but the control algorithm has me scratching my head.

Although the time scales are unit seconds, it looks like a PID
algorithm would best provide a stable feedback loop so I started
looking for examples. I checked the message archives, checked the TI
knowledge base, read spra083 and am going through the Wiki sites.
Using Google, I'm finding some PID source examples, implemented in
floating point but the MSP430 is pretty much an integer part. I am
getting the impression that PIDs are typically implemented from
scratch. Did I miss something?

The PID algorithm doesn't look that hard and tuning the parameters
appears to be straight forward. I just wanted to make sure I didn't
over look the obvious.

Thanks,
Bob Wilson Start a New Thread

----- Original Message -----
From: "Robert J. Wilson"
To:
Sent: Wednesday, December 06, 2006 2:06 PM
Subject: [msp430] PID vs MSP430F2013
> Hi folks,
>
> My application adjusts a voltage while monitoring and recording the
> adjustment. My plan is to use one pin to generate a PWM control signal
> into a driver transistor and use another pin-pair to monitor the
> output voltage. Recording the PWM value will tell the offset of the
> original signal. Right now, I'm looking at using three pins: (1) PWM
> output, (2) ADC input, and (3) ADC ground. This looks fairly straight
> forward but the control algorithm has me scratching my head.
>
> Although the time scales are unit seconds, it looks like a PID
> algorithm would best provide a stable feedback loop so I started
> looking for examples. I checked the message archives, checked the TI
> knowledge base, read spra083 and am going through the Wiki sites.
> Using Google, I'm finding some PID source examples, implemented in
> floating point but the MSP430 is pretty much an integer part. I am
> getting the impression that PIDs are typically implemented from
> scratch. Did I miss something?
>
> The PID algorithm doesn't look that hard and tuning the parameters
> appears to be straight forward. I just wanted to make sure I didn't
> over look the obvious.
Where I used to work they implemented PID motor speed control on an AVR, to
replace the simple 'bang-bang servo' software that I had originally used.
They did it from scratch, in assembler, and had a great deal of trouble
getting it to work properly.

Leon Start a New Thread

I concur with Leon.

Implementing the PID algorithm itself is quite straightforward, but from experience myself,
the hardest part is _tuning_ the PID's coefficients !

Also bear in mind that often the Integral part is not needed in control/servo loops.
The integral is only there to have better "fine" steering. The idea is that when the loop is near
closed that small errors integrate over time into bigger errors, thus yielding a higher precision.
Many applications don't require this. The integral also creates more headaches in that when the
error builds up and the controlled element isn't catching up fast enough, the error will build up
rapidly & excessively. When the control element can catch up better again, the PWM (in your case)
will saturate and go berserk for a while and then badly overshoot. Avoiding this is called
"anti-windup".

But there are many advantages to using the Integral as well.
I'm confused by the mention of floating point though. I've done many PID apps in motion control,
and I've never needed floating point, in fact I don't think I've ever used more than 24 bit signed
integer in the PID interrupt.
.. And I love floating point :-)

HTH.
Best Regards,
Kris

-----Original Message-----
From: m... [mailto:m...] On Behalf Of Leon Heller
Sent: Thursday, 7 December 2006 1:31 AM
To: m...
Subject: Re: [msp430] PID vs MSP430F2013

----- Original Message -----
From: "Robert J. Wilson"
To:
Sent: Wednesday, December 06, 2006 2:06 PM
Subject: [msp430] PID vs MSP430F2013
> Hi folks,
>
> My application adjusts a voltage while monitoring and recording the
> adjustment. My plan is to use one pin to generate a PWM control signal
> into a driver transistor and use another pin-pair to monitor the
> output voltage. Recording the PWM value will tell the offset of the
> original signal. Right now, I'm looking at using three pins: (1) PWM
> output, (2) ADC input, and (3) ADC ground. This looks fairly straight
> forward but the control algorithm has me scratching my head.
>
> Although the time scales are unit seconds, it looks like a PID
> algorithm would best provide a stable feedback loop so I started
> looking for examples. I checked the message archives, checked the TI
> knowledge base, read spra083 and am going through the Wiki sites.
> Using Google, I'm finding some PID source examples, implemented in
> floating point but the MSP430 is pretty much an integer part. I am
> getting the impression that PIDs are typically implemented from
> scratch. Did I miss something?
>
> The PID algorithm doesn't look that hard and tuning the parameters
> appears to be straight forward. I just wanted to make sure I didn't
> over look the obvious.
Where I used to work they implemented PID motor speed control on an AVR, to
replace the simple 'bang-bang servo' software that I had originally used.
They did it from scratch, in assembler, and had a great deal of trouble
getting it to work properly.

Leon

Yahoo! Groups Links Start a New Thread

They are simple to implement. I wrote one for the MSP, but it also is using
float. However, the initial code used integer, and apart from changing data
structures, the algorithm pretty much stayed the same. I should not this
implementation is the position form, not the velocity form, which does have
some advantages. You are welcome to the routine if you just want to check
it out...

/Bill
On 12/6/06, Robert J. Wilson wrote:
>
> Hi folks,
>
> My application adjusts a voltage while monitoring and recording the
> adjustment. My plan is to use one pin to generate a PWM control signal
> into a driver transistor and use another pin-pair to monitor the
> output voltage. Recording the PWM value will tell the offset of the
> original signal. Right now, I'm looking at using three pins: (1) PWM
> output, (2) ADC input, and (3) ADC ground. This looks fairly straight
> forward but the control algorithm has me scratching my head.
>
> Although the time scales are unit seconds, it looks like a PID
> algorithm would best provide a stable feedback loop so I started
> looking for examples. I checked the message archives, checked the TI
> knowledge base, read spra083 and am going through the Wiki sites.
> Using Google, I'm finding some PID source examples, implemented in
> floating point but the MSP430 is pretty much an integer part. I am
> getting the impression that PIDs are typically implemented from
> scratch. Did I miss something?
>
> The PID algorithm doesn't look that hard and tuning the parameters
> appears to be straight forward. I just wanted to make sure I didn't
> over look the obvious.
>
> Thanks,
> Bob Wilson
>

--
This message was sent from my Gmail account. You can use either
w...@comcast.net or email to this account directly. Start a New Thread

Thanks Bill,
--- In m..., "William Sell" wrote:
>
> They are simple to implement. I wrote one for the MSP, but it also
is using
> float. However, the initial code used integer, and apart from
changing data
> structures, the algorithm pretty much stayed the same. I should not
this
> implementation is the position form, not the velocity form, which
does have
> some advantages. You are welcome to the routine if you just want to
check
> it out...

I would like to take a peek at it.

I appreciate the problem of 'tuning' the coefficients but that is the
fund of dealing with the real world. This first project will be
followed by others with more challenging systems.

Bob Wilson Start a New Thread

One thing you need to watch out. Even after low pass filtering, the
output voltage will have ripples at the PWM frequency. You may see
strange things in your ADC readings depending on the phase of the
ripples when the ADC samples.

--- In m..., "William Sell"
wrote:
>
> They are simple to implement. I wrote one for the MSP, but it also
is using
> float. However, the initial code used integer, and apart from
changing data
> structures, the algorithm pretty much stayed the same. I should
not this
> implementation is the position form, not the velocity form, which
does have
> some advantages. You are welcome to the routine if you just want
to check
> it out...
>
> /Bill
> On 12/6/06, Robert J. Wilson wrote:
> >
> > Hi folks,
> >
> > My application adjusts a voltage while monitoring and recording
the
> > adjustment. My plan is to use one pin to generate a PWM control
signal
> > into a driver transistor and use another pin-pair to monitor the
> > output voltage. Recording the PWM value will tell the offset of
the
> > original signal. Right now, I'm looking at using three pins: (1)
PWM
> > output, (2) ADC input, and (3) ADC ground. This looks fairly
straight
> > forward but the control algorithm has me scratching my head.
> >
> > Although the time scales are unit seconds, it looks like a PID
> > algorithm would best provide a stable feedback loop so I started
> > looking for examples. I checked the message archives, checked the
TI
> > knowledge base, read spra083 and am going through the Wiki sites.
> > Using Google, I'm finding some PID source examples, implemented in
> > floating point but the MSP430 is pretty much an integer part. I am
> > getting the impression that PIDs are typically implemented from
> > scratch. Did I miss something?
> >
> > The PID algorithm doesn't look that hard and tuning the parameters
> > appears to be straight forward. I just wanted to make sure I
didn't
> > over look the obvious.
> >
> > Thanks,
> > Bob Wilson
> >
> >
> > --
> This message was sent from my Gmail account. You can use either
> w.sell@... or email to this account directly.
>
> Start a New Thread

>Implementing the PID algorithm itself is quite straightforward, but from
>experience myself,
>the hardest part is _tuning_ the PID's coefficients !

I would first recommend learning about closed loop PID control. Like others
have stated, the algorithm is not very difficult to do. But learning all
about PID control, picking coefficients, and determining how to do
auto-tuning (if desired) is more difficult - in that order. A good book I
had on the subject (someone stole it) is by David St. Clair called
"Controller Tuning And Control Loop Performance, A Primer, Second Edition"
subtitled "PID Without the Math". The URL for it is:

http://members.aol.com/pidcontrol/booklet.html

>Also bear in mind that often the Integral part is not needed in
>control/servo loops.
>The integral is only there to have better "fine" steering. The idea is that
>when the loop is near
>closed that small errors integrate over time into bigger errors, thus
>yielding a higher precision.

I would say an integral is always necessary if you want to be sure to have
the PID settle on the target setpoint. Otherwise, offset errors can
persist.

>Many applications don't require this. The integral also creates more
>headaches in that when the
>error builds up and the controlled element isn't catching up fast enough,
>the error will build up
>rapidly & excessively.

I would say most applications should use integral control. It is like
setting a speed on your cruise control and having the car track a speed a
few MPH off - it just is not good and a little effort can make it track
right on. As far as rapid or excessive wind-up of the integral portion,
that can all be controlled by how you implement the integral. You can even
add some fuzzy logic to the integral calculations. I would never throw out
the integral.

>When the control element can catch up better again, the PWM (in your case)
>will saturate and go berserk for a while and then badly overshoot. Avoiding
>this is called
>"anti-windup".

Only if he lets it do that. Just limit how much and how fast the integral
"integrates".

>I'm confused by the mention of floating point though. I've done many PID
>apps in motion control,
>and I've never needed floating point

Same here. All of our PID control has been done with either 8-bit or 16-bit
unsigned integers and they work VERY well. We even were able to implement
an auto-tuning feature in one of our products. Depending on the loop speed,
he may not even be able to use floating point, but I guess slower loops
could use it.

Before going out and looking for available PID code, I would be sure you
understand the basics of PID control and loop tuning. In that way, when you
do view others PID code, you know what they are basically trying to achieve
and where they may have taken short-cuts.

Lou

> > Hi folks,
> >
> > My application adjusts a voltage while monitoring and recording the
> > adjustment. My plan is to use one pin to generate a PWM control signal
> > into a driver transistor and use another pin-pair to monitor the
> > output voltage.

> > Although the time scales are unit seconds, it looks like a PID
> > algorithm would best provide a stable feedback loop

_________________________________________________________________
Stay up-to-date with your friends through the Windows Live Spaces friends
list.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk Start a New Thread

Hi Lou,

Nice post - and good to weigh up different opinions.
Implementing the integral is IMO a moot point ("moot" in the context of "open for debate").
There are a lot of app notes out there that encourage implementation of PD instead of PID.
I referred to motion control in general, and you're certainly right - for motion control
the integral is an intrinsic part of loop accuracy. I've always used it myself.
But I referred to motion control in the context of the use of floating point - or lack thereof.
This did not mean I think the integral is not important, I just think that a simple loop such as
the OP's won't need that at all.
For an entry level closed loop such as this it'll probably encourage loop instabilities
and do more worse than good in the beginning.

In the past I've been used to PID interrupts of typ. 1 mS, ie. 1000 samples / second.
Bit cramped for floats (which will get saturated into an 8 bit PWM or some such anyway).
1 second intervals are very relaxed of course.

So basically, it's good you point out the importance of the integral portion, but my post did not
intend to promote disregarding that integral.
Perhaps I worded it wrong.

Best Regards,
Kris

-----Original Message-----
From: m... [mailto:m...] On Behalf Of Lou C
Sent: Friday, 8 December 2006 1:36 AM
To: m...
Subject: RE: [msp430] PID vs MSP430F2013

>Implementing the PID algorithm itself is quite straightforward, but from
>experience myself,
>the hardest part is _tuning_ the PID's coefficients !

I would first recommend learning about closed loop PID control. Like others
have stated, the algorithm is not very difficult to do. But learning all
about PID control, picking coefficients, and determining how to do
auto-tuning (if desired) is more difficult - in that order. A good book I
had on the subject (someone stole it) is by David St. Clair called
"Controller Tuning And Control Loop Performance, A Primer, Second Edition"
subtitled "PID Without the Math". The URL for it is:

http://members.aol.com/pidcontrol/booklet.html

>Also bear in mind that often the Integral part is not needed in
>control/servo loops.
>The integral is only there to have better "fine" steering. The idea is that
>when the loop is near
>closed that small errors integrate over time into bigger errors, thus
>yielding a higher precision.

I would say an integral is always necessary if you want to be sure to have
the PID settle on the target setpoint. Otherwise, offset errors can
persist.

>Many applications don't require this. The integral also creates more
>headaches in that when the
>error builds up and the controlled element isn't catching up fast enough,
>the error will build up
>rapidly & excessively.

I would say most applications should use integral control. It is like
setting a speed on your cruise control and having the car track a speed a
few MPH off - it just is not good and a little effort can make it track
right on. As far as rapid or excessive wind-up of the integral portion,
that can all be controlled by how you implement the integral. You can even
add some fuzzy logic to the integral calculations. I would never throw out
the integral.

>When the control element can catch up better again, the PWM (in your case)
>will saturate and go berserk for a while and then badly overshoot. Avoiding
>this is called
>"anti-windup".

Only if he lets it do that. Just limit how much and how fast the integral
"integrates".

>I'm confused by the mention of floating point though. I've done many PID
>apps in motion control,
>and I've never needed floating point

Same here. All of our PID control has been done with either 8-bit or 16-bit
unsigned integers and they work VERY well. We even were able to implement
an auto-tuning feature in one of our products. Depending on the loop speed,
he may not even be able to use floating point, but I guess slower loops
could use it.

Before going out and looking for available PID code, I would be sure you
understand the basics of PID control and loop tuning. In that way, when you
do view others PID code, you know what they are basically trying to achieve
and where they may have taken short-cuts.

Lou

> > Hi folks,
> >
> > My application adjusts a voltage while monitoring and recording the
> > adjustment. My plan is to use one pin to generate a PWM control signal
> > into a driver transistor and use another pin-pair to monitor the
> > output voltage.

> > Although the time scales are unit seconds, it looks like a PID
> > algorithm would best provide a stable feedback loop

_________________________________________________________________
Stay up-to-date with your friends through the Windows Live Spaces friends
list.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi
.aspx?wx_action=create&wx_url=/friends.aspx&mk

Yahoo! Groups Links Start a New Thread

Hi Kris,

I guess I was a little out of line when I stated:

>I would say most applications should use integral control.

Who am I to know what "most applications" are anyway. :-) What I think I
wanted to get across is the design should always start with all the
capabilities of PID control, namely P, I, and D. And maybe even add some
logic to do things like adding a dead band, clearing integral accumulation
when passing through the dead band, etc. Then smart decisions like you
noted could be made to decide NOT to use one of the terms.

>Implementing the integral is IMO a moot point ("moot" in the context of
>"open for debate").

However, I would bet we would come to violent agreement :-)

>There are a lot of app notes out there that encourage implementation of PD
>instead of PID.

Yes, especially within a well-known application area. The last PID control
product I did was a valve controller. It had to be adaptable to many
different applications - anything that could flow through a pipe! I guess I
wrongly assumed the OP wanted a more generic PID controller. So, I
naturally could not see throwing out any of the terms. We did have some
applications of that valve controller that included only PD and I think even
one that only had PI. I have never seen an application without P. We just
had programmability to take any of the term coefficients to zero if they
were not needed.

>For an entry level closed loop such as this it'll probably encourage loop
>instabilities
>and do more worse than good in the beginning.

That's true for sure. To understand behavior of the loop (if it is totally
unknown), I always recommended starting with proportional only, then adding
the others as needed.

>In the past I've been used to PID interrupts of typ. 1 mS, ie. 1000 samples
>/ second.

That's pretty quick. I did one product once a long time ago with a 1 mS
loop time for a tension control application. I never knew what their final
PID terms were. They were very secretive about everything they did - they
could tell me but they would have to kill me.

>So basically, it's good you point out the importance of the integral
>portion, but my post did not
>intend to promote disregarding that integral.
>Perhaps I worded it wrong.

No, my bad in assuming he wanted a generic controller. Good discussion
Kris!

Lou

_________________________________________________________________
Stay up-to-date with your friends through the Windows Live Spaces friends
list.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk Start a New Thread

Hi Lou,

--- In m..., "Lou C" wrote:
>
. . .
>
> No, my bad in assuming he wanted a generic controller. Good
> discussion

Actually I do but my plan is to design the code to have an external
table of parameters that I can "tweak" during integration and test.
But it might help to share what I'm out to accomplish.

I have a hybrid-electric but the existing cruise control suffers from
a number of limitations:

1) strongly fixed speed - this results in engine braking on the
back-side of overpasses and excessive throttle going up the overpasses.

2) 23 mph low limit - this means it is difficult to use in slow-speed
areas.

3) absence of 'preset' speeds - this makes setting the speed a bit of
'hunt and peck' versus smoothly going to 30 mph, 35 mph, e.t.c.

4) automatic pulse and glide - current manual systems lack
reproducable results. Using a PID speed controller I should be able
tweak it to an optimum solution and validate a vehicle model.

Other control systems of interest include pre-heating the transaxle
oil and wheel bearings. I want to warm them up to a target temperature
and no higher without using "bang the stops."

The MSP430-F2013 has enough interfaces to support more than one
control loop. If not, it is easy enough to separate them to individual
MPS430s. The key is to make sure I write a reasonable, generic PID
'library' with well defined coefficients. The key is to design before
implement and the insights provided have been just what I needed.

Bob Wilson Start a New Thread