View Single Post
Old February 19th, 2003, 02:02 PM   #4
Ron Beaufort
Lifetime Supporting Member
United States

Ron Beaufort is offline
 
Ron Beaufort's Avatar
 
Join Date: Jul 2002
Location: Charleston, SC
Posts: 5,336
Peter and Allen,

Thanks for the feedback. I’ve been tinkering around with this PID stuff on my own for years. It’s nice to finally have someone to offer some constructive criticism on what I’ve been able to come up with.

Allen, you said:

Quote:
The PLC doesn't reaaly "know" the value of dt in the above equations. It doesn't measure the elapsed time, it just takes the value that you enter in the Loop Update Time setting for the b]dt[/b] , and calcuates everything from there.
Not exactly. Remember that not only did I change the Loop Update Time setting - I also changed the timing on the PID’s “trigger” event - the timer done bit which conditions the PID’s execution. Since those two values were always kept “in synch” with each other - the changes that I made did NOT detune the loop. You’re absolutely right that the PID “doesn't really know the value of dt” - in the sense that the “little accountant man” inside the PID box cannot see how often we’re “triggering” him - that is, how often we’re actually making him do his math functions. Specifically, as you also said: “It [the PLC] doesn’t measure the elapsed time ...” Also absolutely true - and THAT’S WHY the PLC fully relies on the programmer to properly set up the “trigger” event (the timer done bit) to match the PID’s “INTERNAL how-often-am-I-supposed-to-be-doing-this-math?” setting. I know that YOU always keep the two settings in sync. In a previous thread, you once mentioned actually going to the lengths of programming a rung just to keep the settings matched. That’s not a bad idea - once we realize just how CRITICAL that “matched values” requirement is.

Basic idea: Consider the “time related settings” of:

(1) the PID’s internal Loop Update Time setting - and
(2) the external event which “triggers” the PID’s execution.

As long as these two parameters are rigorously kept in sync - then we can slide our “how-often-will-we-do-the-PID?” schedule up and down the scale - all the way from “way too often” to “not nearly often enough” - WITHOUT detuning the PID. Just DON’T forget to change BOTH settings - they have to stay MATCHED.

Now that’s my take on it - and ALL of my experiments (and you have NO idea how many, my friends) seem to confirm my opinion. Suggestion: Plug some reasonable values into the printed PID equation - and then solve it for a few iterations. Then decrease the Loop Update Time to half its original setting. Now go back and solve the equation again. Sure - you’ll get smaller (baby step) contributions from the Integral component - BUT (and here’s the trick) realize that the PLC will be doing HIS iterations TWICE AS OFTEN as before - so the net effect will be ZERO change in the Integral’s contribution - OVER THE SAME PERIOD OF ELAPSED TIME. That requirement for TWICE AS MANY “baby step” iterations within the same period of time is critical. So how does the PLC know HOW MANY iterations to perform within a given amount of time?

The PLC relies on the external “trigger” event (usually a timer done bit) to keep track of that “go-now; go-now; go-now” signal for the PID.

And THAT - dear readers - is why I keep harping-harping-harping on maintaining that all important relationship between the PID’s internal “Loop Update Time” setting and the scheduling of the external “trigger” event. If those two settings are not kept in sync, then heaven help you - I can’t.

I am constantly (choose one: amazed, entertained, amused) by individuals who will take one quick look at a PID and say: “Oh, you’ve got your (choose one: Integral, Derivative) setting (choose one: too high, too low).” The truth is, until you’ve confirmed that the timing issues (Loop Update Time setting and external trigger event) are correct, then the Integral and Derivative settings that you see have little or no actual meaning. It’s basically like checking a voltage reading - using a meter which is completely out of calibration.

Now on to Peter’s observations.

Quote:
I thought I previously posted that any thing less than ten samples per period will not be enough ...
Yes, you certainly did - but the most recent Allen-Bradley PLC-5 manual says: “... 1/5 to 1/10 times the natural period ...”. I wanted to demonstrate the results of those “published” settings - for better or for worse.

Quote:
The simulator should update more often than .5 seconds. Try again with a .05 second update. After 20 scans per second your simulation is the limiting factor. To make it short. Your 20 and 30 PID updates/period examples are limited by the simulation and do not show the real improvement. I have my simulations update 10 to 100 times faster than the PID update rate.
I’ll certainly work on “a faster simulator” as soon as time permits. In the meantime, I already have a heat simulator available which has a natural period of 132 seconds. Theoretically, good control should be obtained by updating its PID every 6.60 seconds. This heat simulator also works on a 0.50 update - but I’m thinking that I should be able to alter my “adequate” Loop Update Time by a factor of 13 before I “hit the wall” of the 0.50 simulator update limitation. Calculating: 132 seconds per period divided by 0.50 seconds per update equals 262 updates per period. Now that’s “way often” to execute a loop. I won’t bet the rent - but I think that I’ll still see that going from 6.60 seconds - all the way down to 0.50 seconds - won’t give “substantially better” control. I’ll keep you posted.

Finally, you’re WAY over my head with that fancy math stuff, Peter.

Useless trivia department: Try this, folks. The next time you’re getting your teeth cleaned, ask the hygienist for the technical name for that crud she’s scraping off your teeth. It’s CALCULUS. Now - I ask you - how deeply involved do I want to get with a branch of mathematics which is named after tooth scum?

Now I honestly admire people like Peter who can “integrate” and “derivate” and who really understand all of those squiggly mathematical lines. As far as I’m concerned, calculus is a lot like voodoo - it only works if the victim believes in it - and personally I don’t really BELIEVE. If the truth be known - adding, subtracting, multiplying, and dividing is about all of the “ciphering” that I can handle. And lucky for me - that’s really all that the PLC can do too - and so we usually get along just fine together.

So once again - thanks, Peter and Allen, for your observations - I truly appreciate them. Please - keep them coming.
__________________

2-B ?
Best regards, ----+----] [----+------------( )----
Ron | |
PLC Training Boot Camp | 2-B |
+----]/[----+

I once was lost, but now am found, was blind, but now I see.


Last edited by Ron Beaufort; February 19th, 2003 at 02:14 PM.
  Reply With Quote