PID Without a PhD, Finally

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.

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().

ah. thanks.

Thank you so much. I will learn something I never knew much about.

Back in 1966 when I was finishing up my BSEE I missed the servo class. Never needed it as my career had me doing analog, digital and software design. Design from the component, module subsystem and system design. I loved following my designs from drawing through manufacturing and integration, test and installation. I have multi-million dollar systems in the field right now. But now retired (in 2008) and listening to the scuttlebutt.

My college change my degree a few years back from BSEE to BS Electronics and Computers which is actually more accurate.

I was in on the beginnings of the microprocessor, had an Altair and designed hardware interfaces for it and wrote software in C and assembly including modifying CP/M OS for the hardware interfaces.

Thanks for bringing back great memories!

Indeed I've been wondering whether this stuff was ever done with purely analog electronics. I don't know how far back it goes historically but I imagine quite a way. Optimal control is from the 1940s and I'd expect PID to be much older? I'm clueless though.

I think the 1st generation of CD players had pretty analog control loops for focus and track. This is not too long ago...

The first PID controllers, to my knowledge, were purely mechanical systems. The seminal papers were written in the 1860's, but they were to describe and analyze what had already been in use in industry.

Pneumatic systems were a great innovation in the 1930's (or 20's, or teens).

Electronics doing PID control is a johnny come lately.

Here's Maxwell's paper (yes, James Clerk Maxwell of E&M fame). There was a Russian -- Tchebychev, I think. I can't remember who, nor have I found any papers.

I think that PID control originated in the pneumatic controller days, before there were many (or any) PhDs in control theory. One story that I read suggests that the derivative term was discovered accidentally, the result of a leaky bellows or something.

I designed a state-of-the-art digital boiler/throttle control system for the Navy's LHA helicopter assault ships. The Navy couldn't maintain it so they ripped it out and substituted pneumatics.

PID -- or at least PI -- control has been around longer than that:

Sure thing. About three weeks ago for me. ;)

Cheers

Phil Hobbs

Engineers tend to do

Actuator = error * (Kp + Ki + Kd)

whereas old-time analog controllers did

Actuator = Kp * (1 + Ki + Kd)

with the idea being that it's easier to tune on-site.

I think you mean,

Actuator = error * Kp * (1 + Ki + Kd)

In other words, the Ki and Kd terms were normalized to Kp.

The first PID was used for steering ships and was mostly mechanical:

Uhhhhh... no.

Actuator = (error * Kp) + ( filter1(sum(error)) * Ki ) + ( filter2(delta(error,lastError)) * Kd)

Because trimpots are awesome.

The writing on that is superb. Thanks for the link.