[Dprglist] Better PID Equation for Computing with a microcontroller

[Kipton Moravec]

I meant to send it to the list, but looks like I responded personally. 
Here is the response to the whole list.

*Murry asked:**
**Is there any particular benefit in that u(t) formula over what many of 
the **
**existing PID algorithms do? Or is this just a different way of 
expressing **
**it? *


It is simpler to compute.

And it does not need as much memory.

Sorry about the A thing. It was a copy and paste, and those should have 
been on different lines.

Do not worry about the z transform, it just explains how you get from 
one to another and that the two end equations are the same.

That final u(t) equation is what you are looking for.

u(t )=u(t−1)+ A1 e(t )+ A2 e(t−1) + A3 e(t−2)

u(t-1) is the answer from the previous PID equation

e(t) is the difference between the desired output and the measured output

e(t-1) is the e(t) from the previous time you ran the PID

e(t-2) is the e(t) from two previous times you ran the PID

so after you have computed u(t)

e(t-2) = e(t-1)
e(t-1) = e(t)
u(t-1) = u(t)
for the next time you run the PID calculation

And the equations for the A terms were not clear in the paper.

A1 = Kp + Ki + Kd
A2 = Kp - 2Kd
A3 = Kd

And since the Kp , Ki, Kd terms are constants, the A terms are constants 
also.

This is way faster than worrying about the integration calculation.

If you do not use the Kd term then make it 0, (zero) and it simplifies 
the A2 term and gets rid of the A3 and e(t-2) terms.

I think it is pretty cool. I used it when I ran PID at 50 kHz on a 
simple 16-bit custom microcontroller with a 16 clock multiply 
peripheral. A divide took forever, because it was in software. For that 
project a 24-bit computer would have been ideal. 16-bit was too little, 
and 32-bit was overkill. But I made it work.

Kip


On 10/1/20 3:24 AM, Murray Altheim via DPRGlist wrote:
> On 1/10/20 10:16 am, Kipton Moravec via DPRGlist wrote:
>> I found the writeup of the control equations for the power supply I 
>> did in December 2012 and pulled out just the PID part. The PID is
>> faster for a computer to calculate.
>>
>> I do not remember where it came from, but it is pretty cool and 
>> unrecognizable.
>>
>> I made a PDF because equations do not work in email.
>
> Hi Kip,
>
> Thanks, while I actually took a differential equations course at 
> university
> I will own up to how absolutely minimal is my memory of any of that. So
> when I get to that Z-transform I can kinda make out what it means but on
> my own there'd be no way I'd have figured that out on my own.
>
> That final formula does seem to be quite powerful but you almost lost me
> at the A1 = formula as I didn't notice that specific line was actually
> expressing all three relationships (A1, A2 and A3 are all defined on that
> line). Once I'd (in my head) separated out those three it was clearer on
> how I'd implement that in Python.
>
> Is there any particular benefit in that u(t) formula over what many of 
> the
> existing PID algorithms do? Or is this just a different way of expressing
> it?
>
> Cheers,
>
> Murray
>
> ........................................................................... 
>
> Murray Altheim <murray18 at altheim dot com>                       = 
> =  ===
> http://www.altheim.com/murray/ ===  ===
> = =  ===
>     In the evening
>     The rice leaves in the garden
>     Rustle in the autumn wind
>     That blows through my reed hut.
>            -- Minamoto no Tsunenobu
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20201001/48ca7f8b/attachment.html>