PID Without a PhD, Finally

Well, I'm of the old school, where you define NDEBUG in your production code, rather than using assert() as a shorthand for fatal runtime errors.

Cheers

Phil Hobbs

--
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

;)

Cheers

Phil Hobbs

--
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 think derivative is better, it is about the first derivative of the feedback signal after all. Since it is the result of differentiation "differential" gets in use but in electronics differential is used a lot as in "differential signalling", which has little to do with that. Unless I got it totally wrong this is what causes some confusion (not much though, anyone who wants to dig into it and understand what you are teaching will figure it out and if not it will be hopeless anyway).

Dimiter

I think this is the best approach anyway. Whoever will be reading your pdf will not be an idiot and will think of such implications. I went through the thing - for may be 5 minutes - and never did I stop and think "this should have been done otherwise".

Flooding it with less relevant details will harm it I think.

Then the speed implication is not always true - on one FPU I am familiar with multiplication costs 2 cycles vs. 1 (dual vs. single). On another core I am considering at the moment it is 1 cycle in both cases. Well if the FPU is some 32-bit only cripple and using

64-bit fp will result in some emulation which takes forever things are much worse of course, but you are teaching PID with the paper, not the basics of programming.

Dimiter

What data type to use when is actually not a trivial decision, and it pretty much boils down to benchmarking candidates on your target system.

--

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

Then there is no point in including it is there? I run into this sort of thing in reviewing presentations. An item is inserted, but not clearly. I point out the shortcoming and get the reply that it isn't important to the presentation. I ask them why it's in there then.

I'm not trying to duplicate the examples, I'm trying to understand them. The math, presented in a clear way, helps.

It doesn't have to be exhaustive, but it at least needs to be clear. Including equations that can't be easily found other places with an explanation only confuses the matter. Or did I miss some sources I should have found?

--

Rick

I want to thank all who have commented. I've incorporated some of your suggestions, allowed other suggestions to color what I've done, and chosen not to implement others.

But all of your suggestions were considered, and I'm grateful for your help.

--

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

When I tried moving the proportional block (in analog land) I found I had to move the gain till after the P mixing stage, rather than right into the error signal. (and think more about noise in the integrator.)

George H.

I would have thought that derivative is just differential as dt->0. When dt > 0 you have a difference equation, as in digital control. If you implement PID in analog and have a true derivative, call it that.

Clifford Heath.

A port of C to the Control Data CDC Cyber used the entire 60-bit word for a character. I thought it was terribly wasteful at the time, but now it's obvious that if you were stupid enough to want to write a word processor for one, you'd write code that packed 10 6-bit chars into a word solely for bulk text.

Clifford Heath.

A very tiny nit in the opening sentences:

"I both consult and teach in the area of digital control. Through both of these efforts..."

May I suggest:

I consult and teach in the area of digital control. Through these efforts...

Am 15.04.16 um 00:03 schrieb Tim Wescott:

I've had a cursory look. I'm a physicist myself with only basic knowledge of PID control, so for me the math boxes were helpful. You did not define all variables there, particularly the dependent variables. In equation (1), I wondered whether theta_m is the angle or angular velocity of the motor. That t is time seems fairly obvious, but I'd put both in for clarification. Same for equation (2).

Your plots need some typographical adjustment. The lines are too thin and the fonts are too small. I would also put the variables on the axis, i.e. "Time t in seconds" etc.

The complete controller is a short function which fits in one page. Maybe it is better to put it at the beginning, giving different colours to the proportinal, integral and derivative term, and then explain it. While reading the code snippets, I was wondering what are the fields in the pid structure etc.

For some reason, I find the code on paper quite hard to read. Maybe it's the syntax highlighting that I'm used to when reading on the screen. You can do some basic highlighting using the listings package to improve on that.

Christian

AIUI differential equations is where you have two (or more) interacting models (eg: population of rabbits, population of foxes) and then you've got to simplify to a sigle model.

--
  \_(?)_

Am 16.04.2016 um 11:12 schrieb Jasen Betts:

Not really. Differential equations are equations containing one or more derivatives of a given function, and usually the function itself, too. I.e. they deal in continuous, non-quantized quantities, and differentiable functions. Their solution, if it can be found, is the function itself. The simplest one is

d/dt y(t) = k * y(t)

Its general solution is

y(t) = k1 * exp(k*t)

If there's only one independent variable in play like in this example, they are "ordinary" differential equations, or ODEs. If there are several, e.g. two or three spatial coordinates, they're "partial" differential equations, or PDEs (because they contain "partial" derivatives). There can be systems of DEs, too. The most famous system of PDEs must be that of Maxwell's equations for electro-magnetism.

Those population models you mentioned are usually done as _difference_ equations, where all quantities are treated in discrete steps of the independent variable, time: something like years, seasons, procreation cycles. The rabbits and foxes case is a system of two coupled ordinary difference equations, like this:

r[next_year] = k1 * r[this_year] - k2 * f[this_year] f[next_year] = k3 * f[this_year] + k4 * r[this_year]

Fair enough. I don't think it would be unreasonable to point out that it is covered in your book, or to give a direct link to the book in your pdf. This is part of how you make your living, and people who enjoy and benefit from this paper may like to buy the book too. (I bought it myself, many years ago - but unfortunately I lost it in a house move before I had read more than the first chapter or so!)

It seems to have died out as an idea. There were several problems with the proposed standard - basically it was too little, too late (people already use their own fixed point libraries), too complicated and ugly (with all these "_Sat long long _Fract" types), underspecified (there was nothing equivalent to , meaning you could not use them for portable programming), and there is little in the way of implementations for them. If there at least were types named "sfract_1_15_t" rather than guessing if that might be "short _Fract" or "_Fract", there would have been a chance.

gcc has sort-of support for these fixed point types on some targets (such as ARM). It is not complete, and code generation could do with a great deal of work. It's not bad for simple arithmetic on a single type, but if you mix types or doing something more complicated, it's awful. And mixed type arithmetic would be one of the main advantages of built-in types rather than simple functions.

I think it is more realistic to hope for a standardised C++ template class library for fixed point than for it to be an official part of future C standards.

I'd still suggest that if 32-bit IEEE is not enough, then just use "double". After all, how many systems are there where "float" is big enough (say, 32 bits of significand) but where "double" would not be suitable?

Anyway, if you want to do a check on something like this, you don't use "assert" - use a static assertion:

static_assert(sizeof(real_t) * CHAR_BIT >= 64);

(This is the main reason for using C11. And if you don't have C11, a static assertion macro is easy to make, even if the error messages are ugly.)

Differential equations may be used for that, but that is not what a differential equation is. It is one which uses a function and at lease one of its derivatives. These equations only have closed form solutions in a small percentage of cases and often require special techniques for solving them.

--

Rick

Am 15.04.2016 um 22:05 schrieb Tim Wescott:

Which is why a static_assert() is so strongly preferable over assert(), wherever applicable: instead of trying to figure out which of your assert()s might have triggered the panic LED at run time (invariably at a customer site, 9 time zones away through heavy weather), you get a message at compile time, right there in the coziness of your place of work.

static_assert() solves most of the perceived problems that drive people to demand the C preprocessor should know about things like sizeof().

IIRC my car disables cruise below 30 MPH or so, anyway.

Tim

--
Seven Transistor Labs, LLC 
Electrical Engineering Consultation and Contract Design 
Website: http://seventransistorlabs.com