PID Without a PhD, Finally

Thanks Tim. That last sentence rang a bell in my head and turned on a light. I guess I officially "learned something" today.

There are a few workarounds for this sort of problem that I've collected. I 'm not at my computer, but IIRC the two main ones are specifying -j0 to dvi ps and then

-dEmbedAllFonts to ps2pdf.

Cheers

Phil Hobbs

A very nice work. I seem to remember that you already had a previous version of it, didn't you?

It was a surprise to see that the D box input (and pehaps P) is taken from the feedback and not the error signal, as os usual in most textbooks. For constant or slow varying commands, it makes no difference. Is this arrangement an empirical result?

Pere

Rick:

Every motor is also a generator. For a motor with constant magnetization, the back EMF is proportional to the speed and the motor torque is proportional to the current.

You can model such a motor with a series connection of the supply voltage, the motor (and line) resistance and the back EMF. The motor settles to a speed near such speed that the difference between supply voltage and back EMF runs just enough current in the circuit to compensate for torque needed to keep the speed.

If you feed a constant-magnetized motor with a constant current supply, the torque stays constant until the compliance limit of the feed supply.

--

-TV

Well in general good other comments people have stated I would add these points -

1/ Code layout on page 14 of the integral state is UGLY, belongs in obfuscated C better laid out out that is easier to read at a glance is better for those trying to understand. 2/ Sampling time and loop delay, the closed loop problem that many people overlook is not mentioned in any manner until into the maths. Most people forget that digital control systems have a time lag and time between calculations, sampling and worst of all ALL systems have a delay between command -> error -> drive -> feedback Each part has its own intrinsic delays/inertia and other effects that most people never MEASURE.

Increasing sampling rate or precision does NOT guarantee being able to get to target faster.

A classic problem I saw was a remotely operated vehicle, with a video link and command back to vehicle. Everybody was annoyed that it could not be driven faster than 30 mph so were looking at using 3D cameras to make it faster. No one had obviously measured delays in system

Camera frame integration time Camera frame transmission time Camera frame acquisition time frame compression encryption time frame radio link transmission time frame receive time (missed/corrupt data) frame decryption time frame network transfer time (multi-computer setup) Frame ROTATION by 90 degrees time Frame mixing with other graphics Frame buffer switching

Then Operator response time Controls delay to data time Controls network transfer Controls radio link transmission Controls receive time (what about missed/corrupt data) Controls entered as new commands into drive control loops Controls being applied Vehicle lag to changes in drive

So how was 2 video feeds going to speed this up

3/ Limits (especially integrator)

Limits, limits, limits how often overlooked and bear NO relation to reality.

Examples

If you have a motor with NO direction control, under what circumstances do you need a NEGATIVE limit ?

If you have a maximum drive (output level) under what circumstances do you need a larger limit ?

Real world as in your heater example if you measure ambient unless you have some cooling system your minimum IS AMBIENT.

Light drives can you really have negative light without use of mirrors or other light sources. Ambient light or black is your minimum.

Case I saw was some control software 30 years ago where a PI example program had

Oven Heater constant heat drive Door that could be open or closed 2 temperature readings Oven Ambient

If you left the door closed the integrator would easily reach 50,000 degrees C

If you opened the door it would 'cool' to -500 degrees C and beyond

Just some random ramblings from a nutter to bear in mind

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk 
    PC Services 
  Raspberry Pi Add-ons 
 Timing Diagram Font 
 For those web sites you hate

OOps just spotted a terminology blunder

Page 2 The "PID" in "PID Control" stands for "Proportional, Integral, Derivative".

Page 19

Section Title is "Differential" Should be "Derivative"

From there on you interchange differential and derivavtive all over the place.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk 
    PC Services 
  Raspberry Pi Add-ons 
 Timing Diagram Font 
 For those web sites you hate

See "A Meeting with Medusa" by Arthur Clarke. (Really a good story.)

Cheers

Phil Hobbs (who's not qualified to comment on Tim's magnum opus.) ;)

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC 
Optics, Electro-optics, Photonics, Analog Electronics 

160 North State Road #203 
Briarcliff Manor NY 10510 

hobbs at electrooptical dot net 
http://electrooptical.net

I would not have said it was obfuscated - but it certainly could be a little better (as could the code on page 22). So far, I have only looked at the style of the code - I haven't actually looked at the details to see what it does, nor have I had time to read the whole paper. Hopefully I will do so some time - but perhaps by then there will be a second version from feedback from others in this thread!

As this code is for embedded systems, it should be written in a manner close to that used in common embedded coding standards such as MISRA. Here are some points here that I think would make the code clearer, as well as more compatible with things like MISRA, and more suitable for flexible use in embedded systems:

1. MISRA does not approve of native types such as "double", because the precision is implementation defined and can vary between C compilers and targets. I agree with that regarding integers (so use types rather than "int" or "short"), but the use of 32-bit and 64-bit IEEE formats for "float" and "double" is so close to universal that I think it is unnecessary. However, many people using code like this will want to use "float" for speed, while others will want "double" for precision. I would recommend starting the code with:

typedef double real_t; // Use "float" or "double" as desired

Then use "real_t" throughout, instead of "double".

(It may be interesting to have a small section discussing the merits of these options - on something like a Cortex-M4F with hardware single-precision floating point, the speed difference could easily be a factor of 100. It may even be worth mentioning things like compiler flags - while most people know about basic optimisation flags, they may not know the huge difference "-ffast-math" can have on code like this. You may also want to discuss using integers instead of floating point, especially considering errors, scaling, rounding, and overflows.)

1. Do not give identifiers names such as "dState" and "iState". There are, unfortunately, a good many programmers who have totally misunderstood the point of "Hungarian notation" and will think that these mean a variable "state" with type "double", and another variable "state" with type "int".

1. Do not give identifiers names that are almost the same. Do not abbreviate the important part of the name (the "differential" or "integrator" part) to a single letter. It's fine to have shorter names for local variables within a function, but names that are visible over a wider range (such as the struct fields) should be self-explanatory.

2. If you need a comment to tell you what an identifier is, then the identifier name is bad. It is the identifier's name that says what it is - a comment may be used to add extra information such as scaling, or when it is used.

1. Always use the "one true brace" style. Every "if" and "else" should have brackets.

2. Do not declare more than one identifier in the same declaration.

1. Even the most conservative and backwards development companies have heard of C99. Declare your variables when you need them, in the smallest reasonable scope.

Full marks for good character spacing!

typedef double real_t; // Use "float" or "double" as desired

typedef struct { real_t lastPosition; real_t integrator; real_t integratorLimitMax; real_t integratorLimitMin; real_t integralGain; real_t proportionalGain; real_t derivativeGain; } pid_s;

real_t updatePID(pid_s * pid, real_t error, real_t position) { // The "P" part real_t pTerm = pid->proportionalGain * error;

// The "I" part pid->integrator += error; if (pid->integrator > pid->integratorLimitMax) { pid->integrator = pid->integratorLimitMax; } else if (pid->integrator < pid->integratorLimitMin) { pid->integrator = pid->integratorLimitMin; } real_t iTerm = pid->integratorGain * pid->integrator;

// The "D" part real_t dTerm = pid->derivativeGain * (pid->lastPosition - position); pid->lastPosition = position;

// Combined PID result return pTerm + iTerm + dTerm; }

Note that almost no comments are needed - the functionality is clear from the names used in the code.

Regarding the typesetting, I recommend using the "listings" package rather than just a verbatim environment:

The setup I use for C code is something like this:

\lstset{ language=C, formfeed=\newpage, tabsize=4, basicstyle=\small, numbers=left, numberstyle=\tiny, firstnumber=1, numberfirstline=true, stepnumber=5, numbersep=5pt, extendedchars=true, showstringspaces=false, breakatwhitespace=false, identifierstyle=\color{Black}\itshape, commentstyle=\color{Gray}\itshape, stringstyle=\color{Green} }

(I vary it a little according to the document in question, but this is probably fine to get you started.)

Ok, that all makes sense and is what is being described in the paper. The drive is current rather than voltage and will produce the result shown in the diagram until the max voltage of the supply is reached. Thanks.

I still don't get equation 3. I searched a bit and could not find anything similar. All the other references I found on the web use the Laplace transform to perform the math and don't produce a similar equation.

Trying to find info on the web for control theory really opens a rabbit hole, lol.

--

Rick

Thermal systems are generally far more complex than equation 3 implies. That one really should be taken just add the equation used to generate the plant model, nothing more.

Pragmatically, if you need to wrap a control loop around a thermal plant, you should probably close your eyes to the theory and either tune it up by the seat of your pants (as in that paper), or you should use measured responses (which I cover briefly in another paper, and at length in my book).

--
www.wescottdesign.com 


----Android NewsGroup Reader---- 
http://usenet.sinaapp.com/

Yes. It was published in Embedded Systems Design magazine back in 2000 or something. For years I've just pointed to their version in my website, but they keep moving it around as their priorities change.

Textbooks make things easy to understand. Practitioners make things work well. (Snarkity-snark).

I kind of allude to this in the text -- I could add a section. Basically, if you feed the entire error signal to the PID controller then when you have a step-change in the input you just hammer the output driver of the controller. Sometimes this is a good thing, because you get snappier response from the plant. Sometimes this is a bad thing, because if you've got a lot of extraneous changes in the command you can heat up (or wear out, or whatever) your output driver.

--

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

I haven't read it all, yet. (I think I've seen this before? on your website?)

Anyway I just wanted to ask about figure 2. I've always put the D block in parallel with the P and I block... all after you generate the error signal. (and gain that up.) Is there a reason/ advantage etc. for putting it where you've drawn it?

Do you talk at all in the paper (or your book) about the P-term in dotted outline that you've got as "negative feedback around the plant". (Well I don't see a sign designation for where that goes into the summing block. I assume it's negative.)

I'm going to try that on my next PID thermal project. (Hopefully next week.. assuming no more new fires to put out.)

George H.

Argh! yes. Thank you.

--

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

Hi David:

Thank you for your pertinent comments. I think I'll apply most of them. The only scary part of your comments are the "if someone uses the code"

-- I originally meant this code to be for illustrative purposes only, not for use in production systems. My assumption was that people would read the article, grok the material, then go off and write code from scratch.

Thus, the first time I got feedback along the lines of "we copied your code into our production software and it works GREAT!" my response was

"WHAT!?! NOOOO!"

So I would be tempted to take your real_t and change it to do_not_use_this_for_real_t.

I have a question, since you brought it up and since I'm lazy. In many control systems, 32-bit IEEE floating point is inadequate, because a 24 bit significand just doesn't cut it. So the choice of double, with its bigger significand, is usually necessary.

Is there a better way to express the "you damned well need 'double' here, bub" in code than just using "double", or a comment to that effect?

--

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

That calls for clarification. "Derivative" is the correct term if you're doing the work with continuous-time hardware (i.e. op-amps, resistors and capacitors). "Differential" is the correct term if you're doing the work in sampled time.

So I need to figure out how to work that in.

--

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

I double-checked, and I kind of allude to this but I need to SAY this in the text. Thermal systems are generally sluggish with lots of high- frequency roll-off. The model chosen is sluggish with lots of high- frequency roll-off. That's about the extent of the accuracy of the model, in general. On a good day the chosen model may actually match a real thermal system well enough to work with -- but it's not to be taken as a generally accurate model, where equations 1 and 2 are generally much more applicable.

--

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

Yes. It's posted somewhere on the CMP (Embedded Systems Design) website, but they keep moving it around. I decided I needed to bring it home.

Yes, I talk about it in my book. I _hope_ I mention it in the paper beyond what I said in the title.

Moving the blocks around changes how the thing responds to input, without changing how it responds to disturbances. If having the absolute fastest response to a step input isn't important, but having less overshoot, or driving the plant less hard, etc., _is_ important, then moving the derivative (and maybe the proportional) blocks out of the feed-forward path is a Good Thing.

--

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

That is why papers often use pseudo code rather than real code that can be copied.

How about a comment that you shouldn't be doing this unless you actually understand what is happening?

--

Rick