PID Without a PhD, Finally

Yes, I understand a real system may be more complicated. But as I've said before, if I can't understand what an equation means, I have a very hard time understanding how to use it. I just need to "get" the equations you use as examples. This one eludes me and you seem to be saying you sort of made it up without a physical basis. You said you invented not one, but two time constants.

Here's how you use that equation within the intended context of the paper:

• Look at it.
• Say "oh, it's math".
• move on.

Seriously. If you're not trying to duplicate the examples, you _do not need the math_. That's the point of the paper.

Because then you would never start. Possibly 90% of the control loops in the world are implemented by people who have no greater understanding of control theory than what's presented in that paper. I'm not trying to turn people into control engineers, I'm trying to supply a pragmatic solution to a large class of real-world problems.

"Differential equations" are what you need to describe things in a continuous-time world (the three equations in the paper are differential equations).

"Difference equations" are what you need to describe things in a discrete- time world.

Lots of high frequency rolloff and even more high frequency phase shift. In thermal diffusion, you get another radian for every 1/e amplitude decay, which makes PID kind of disappointing IME.

My TC loops are always pretty simple--diode lasers on TECs, or resonators with a heater--but after the nonlinearity is taken out, I can usually get away with a plant model of a time delay followed by an integrator. You can read the parameters right off the scope trace. I'm perfectly sure that was invented a very long time ago, but it works great for smallish stuff.

Cheers

Phil Hobbs

I may change my model.

Probably the most important temperature loop I've ever closed (the temperature of a focal plane array, cooled by a split-cycle Stirling cooler) had a simple 1st-order dominant pole, with no discernible excess phase shift or attenuation until well past the practical loop closing frequency. I was happily astonished.

ChuckE2009

Plus you were a hero. It's nice when things work out that way.

One time when I was a post-doc, a colleague needed a notch filter to get rid of a 30-kHz resonance in the piezo tube actuator of the STM he was building. I reached into my bench drawer, pulled out a largish Pulse Engineering transformer, and parallel-resonated both sides with a 0.1 uF cap on it, just as a first try.

Stuck a sweep generator and scope on it, and what came out was a nearly symmetrical two-bump notch exactly at 30 kHz, with a Q of about 30.

Then of course I just quietly handed it to him, smiled, and went back to work. Never did let slip that it was a total fluke. ;)

I still don't know where the beautiful two-bump notch shape came from--leakage inductance and capacitor tolerance, I suppose.

Cheers

Phil Hobbs

You might want to give that section a better title than "The Complete Controller", with the program description "Here is the full text of the PID controller code" :-) Perhaps a big warning in red that this is example code to get started.

In a good many systems, double is not good enough either - it will be too slow. The developer needs to use some sort of scaled integers to get 32 bits of precision (especially in the integrator), and may even need to use 64-bit integer arithmetic for intermediary results.

It would be nice if there were some equivalent to that defined types like float32_t and float64_t, but there isn't one. There are some macros in defining aspects of floating point types, but they are a bit ugly - and since you are always going to have 32-bit IEEE floats and 64-bit IEEE doubles (unless your compiler cheats by using 32-bit doubles, as you sometimes see on small micros), there is nothing there worth checking. If 32-bit IEEE is not good enough, just write "double" - and make a note that it has to be a /real/ double, not a non-standard 32-bit version.

So is the use of the title "Differential" correct or not? I'm a bit confused. Above you say "Derivative" is the term for use with continuous time systems and "Differential" is for sampled time systems. Here you say "Differential" is the correct term for use with continuous time systems and "Difference" is used with sampled time systems.

assert(sizeof(real_t) >= 8);

Cheers

Phil Hobbs

I should make sure that the speed problems with double are pointed out -- I think I mention it, but I may have been so totally focused on just showing the implementation in the simplest way possible that I forget.

My preference if I'm doing a complicated control system is to use a fractional arithmetic type, where the underlying storage is twos compliment integers but the functional type has values that range from almost -1 to almost +1. You grab integer data, scale it to a fractional, do all the control calculations in fractional, and then convert back to integer to apply to a DAC or PWM generator or whatever. Implementation can be in either C or C++, although you can make more readable code with C

I cover various data types (including ints, fractional, and the pitfalls of floating point) in my book. There's enough to fill a chapter. You do need to have a good understanding of what's happening to the data under the hood if you're going to do controls or signal processing.

Which reminds me -- at some point I remember seeing that fractional arithmetic was a suggested type for C, but I never kept track of whether it went someplace useful or is a dead end.

For all that, there are useful control loops to be closed out there that can profitably use double-precision floating point on a PIC or an 8051 -- just not too many of them.

That would give a false alarm on some DSP chips, because sizeof returns the number of characters your variable or type fits into, and if the processor can't handle data in chunks as small as 8 bits a character is bigger (usually 16 or 24, but I believe that it was 32 or 64 in some Cray machines).

Fortunately, in a compliant compiler this is captured in CHAR_BIT:

assert(sizeof(real_t) * CHAR_BIT >= 64)

I oversaw the introduction of the TMS320F2812 into a product line where we had code that had worked for YEARS, which broke because of the implicit assumption that the number of bits in a character was 8.

A differential equation uses derivatives.

A difference equation uses delays, but relies heavily on the concept of a first difference (x_n - x_{n-1}) if you're modeling real-world phenomenon.

Please don't blame me for the terminology -- folks have been using this since before I was born, I'm just the messenger.

Am 15.04.2016 um 20:48 schrieb Phil Hobbs:

That won't actually work reliably. Remember that sizeof's result is in "bytes", as in: whatever size "unsigned char" is on the target platform. Which might be bigger than the usual 8 bits, particularly on DSPs. Not all the world's a VAX, and a byte is not 8 bits everywhere.

So if your goal is to insist on a 64-bit floating-point 'real_t', you'll really have to say

assert((sizeof(real_t) * CHAR_BIT) >= 64u);

and maybe, while at it, also make sure it's a floating-point type:

assert(0 != (real_t)0.1);

And for good measure, better make those static_assert()s so they trigger at compile time, instead of trying to abort at run time with a message--- which in an embedded system often has nowhere to go.

the ARM CMSIS DSP lib has Q15,Q31,Q63 formats

I'd think most fixed point DSPs uses a 1.xx format and the MUL-ACC handles the extra shift need for the muliplication

-Lasse

a friend of mine builds aftermarket ECUs, when throttle by wire came along adding a cruise control came natural and it worked perfectly. but, hitting resume at low speed in a low gear was "interesting" :)

was fixed by adding a slew rate limit on the set point

-Lasse

-Lasse

D'oh -- why, of course I'll include an appendix or something on how to do this with op-amps. It should have occurred to me immediately.

I am familiar with the terminology, you seem to be using the terms irregularly. What you say here is correct, but it doesn't clarify the confusion of your other statements. Here you use both differential and derivative in the continuous time domain. Elsewhere you have used the term differential for the discrete (sampled) time domain.