PID Without a PhD, Finally

On 2016-04-15, rickman <gnuarm@gmail.com> wrote:
> On 4/15/2016 1:32 PM, Tim Wescott wrote:
>> On Fri, 15 Apr 2016 14:43:03 +0100, Paul wrote:

>
> I was going to make that comment, but then I recalled the term my 
> professor actually used was "difference equations".  "Differential 
> equations" means something else, no?  I couldn't find any sources on 
> this, so I didn't make the comment.  It's been far too long to trust my 
> memory.

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. 


-- 
  \_(&#12484;)_

Am 16.04.2016 um 11:12 schrieb Jasen Betts:

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

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]

On 15/04/16 20:53, Tim Wescott wrote:

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

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

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

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 <stdint.h>, 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.

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

On 15/04/16 20:59, Tim Wescott wrote:
> On Fri, 15 Apr 2016 14:48:03 -0400, Phil Hobbs wrote:
>
>> On 04/15/2016 01:30 PM, Tim Wescott wrote:

>>>
>>> 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?
>>>
>>>
>> assert(sizeof(real_t) >= 8);
>>
>> Cheers
>>
>> Phil Hobbs
>
> 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.
>

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

On 4/16/2016 5:12 AM, Jasen Betts wrote:
> On 2016-04-15, rickman <gnuarm@gmail.com> wrote:
>> On 4/15/2016 1:32 PM, Tim Wescott wrote:
>>> On Fri, 15 Apr 2016 14:43:03 +0100, Paul wrote:
>
>>
>> I was going to make that comment, but then I recalled the term my
>> professor actually used was "difference equations".  "Differential
>> equations" means something else, no?  I couldn't find any sources on
>> this, so I didn't make the comment.  It's been far too long to trust my
>> memory.
>
> 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.

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:
> On Fri, 15 Apr 2016 21:19:50 +0200, Hans-Bernhard Bröker wrote:

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

> Most of my embedded systems will at least make a light blink oddly when
> you hit an assert -- but that's not a Good Thing normally.

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

On 2016-04-16, rickman <gnuarm@gmail.com> wrote:
> On 4/16/2016 5:12 AM, Jasen Betts wrote:
>
>> 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.
>
> 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.

ah. thanks.

-- 
  \_(&#12484;)_

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!

Tim Wescott <tim@seemywebsite.com> writes:
> 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.

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.

On 26.04.2016 09:30, Paul Rubin wrote:
> Tim Wescott <tim@seemywebsite.com> writes:
>> 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.
>
> 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...