PID Loop Update time and external trigger

[Peter Nachtwey]

all of that having been said: I can’t think of anything to actually prevent you from using the “CV%” location (word #16 of the PID control block) and scaling it as you have ... it looks like it should work OK ... but be aware that this approach gives your PID only 100 steps of resolution for its output signal ... not 16383 steps as would normally result from using the “proper” location ... that might be fine for this particular application, but in many (most?) others just 100 steps would not be enough for smooth control ...

Ron has a good point, but he under estimates the need for resolution. I think you should heed Ron's warning again and use the full range of 0-16383.

 

[leitmotif]

More stuff to do

Greetings Dan,



one more important “issue” that I noticed on your spreadsheet is highlighted below ...

it looks like you have the control block for your PID located at N10:0 ... so the 23 words of the control block occupy N10:0 through N10:22 ... nothing wrong with that at all ... but ...



your approach of taking the “CV%” reading as the OUTPUT of the PID is highly unorthodox ... normally we use the integer memory location which we’ve listed as the “Control Variable” on the PID instruction (on the ladder rung) as the output of the PID - not word 16 of the PID’s control block ... in Figure 2 of my post #11 I used N7:75 as my “CV” ... in normal operation, the PID will drive this location with values ranging from 0 to 16383 ... this “CV” location is the one that SHOULD be used for the input to your final SCP ... of course your program’s address may be different from my N7:75 example ... I’d suggest N10:29 if you’re not already using it for something else ...



normally the value from the “CV%” is used as a readout display for the operator, etc. ... it tells him (in simple 0 to 100% units) how hard the PID is presently driving the output ...



all of that having been said: I can’t think of anything to actually prevent you from using the “CV%” location (word #16 of the PID control block) and scaling it as you have ... it looks like it should work OK ... but be aware that this approach gives your PID only 100 steps of resolution for its output signal ... not 16383 steps as would normally result from using the “proper” location ... that might be fine for this particular application, but in many (most?) others just 100 steps would not be enough for smooth control ...



as I said, your present approach should work ... but I can assure you that it is NOT commonly done this way in the real world ... since you’re obviously trying to learn as much as possible from this exercise, then I suggest (in the friendliest terms) that you “get in step” with everyone else and use the “CV” and not the “CV%” for your PID’s output ...



there are a few other minor issues with things like your “engineering units”, etc. ... but it’s obvious that you’re still working through those types of things ... I for one am going to let them simmer for awhile ... there’ll be plenty of time to tackle them later if you need help ...



it looks like you’re making a systematic approach to mastering this subject ... if either you or your instructor wants to talk about it by phone, feel free to send me a Private Message with a phone number ... I’ve helped quite a few tech schools with this type of stuff in the past ...

REPLY
This thing is "worse" than setting up sequencer. Already did the "lets crank this thing up and see what happens" that worked - got me this far -- now there is no choice but to be systematic.

Ron let me go looking for the correct CV value -- granted CV% seems to work BUT if it is not correct it is not correct.

ALSO will convey you offer to instructor. Have already emailed him some of your PID info.

Like I told Lancie let me go looking and adjusting Tue. Will let you know how made out.

Many thanks

Dan

 

[leitmotif]

Ron,

You are right - the output value is right there in the little PID box in the ladder right where it should be for convenience. I followed the example Rockwell used in the manual on p9 3. I then looked at the data for table N10 and N10:29 seemed OK at 11,620 -- adjusting that to a percent of 16383 comes out to 70.9% - close enough for me to the 71% value shown in N10:16. Revised my spreadsheet. Will fix Tue.

In your reply you said you had your value in N10:75. Why there? That reminded me of something else I have been thinking about. The sequencer instruction has a couple tables. I know you need to keep all this stufff separate so you don't use the same bit of data erroneously - Rockwell cautions on that also.

Do you have some sort of self taught self imposed "list" of where you store various tables etc etc. The value to this is the same data will be in the same location from program to program no matter what company or factory you are at. Would save a lot of hunting around.

Many thanks
Dan

 

[Ron Beaufort]

Greetings Dan,



you said:

In your reply you said you had your value in N10:75. Why there? ... Do you have some sort of self taught self imposed "list" of where you store various tables etc etc. The value to this is the same data will be in the same location from program to program no matter what company or factory you are at. Would save a lot of hunting around.

actually it was N7:75 - not N10:75 ... but your statement “... no matter what company or factory ...” is SO close that I’m going to go ahead and give you the cigar anyway ... actually it’s “no matter what student” I’m working with ...



for years the PID classes that I teach for the PLC-5 platform have always made use of N7:54 as the location of the lab equipment’s first analog input channel ... N7:75 is the location of the first analog output channel ... a lot of that comes from the way that I make the students enter their Block Transfers for the analog input and output modules ... anyway ... when I teach the PID class for the SLC-500 platform, I keep the same input and output addresses to preserve my own sanity (the small amount of sanity that I still have) ...



it also helps when the class is doing their first troubleshooting exercises on the Hotrod trainers ... you have NO idea what a nightmare just teaching the basic concepts can be when each “Sammy Student” has his very own personal set of addresses for his PV and for his CV, etc. ... just sketching the signal flow on the board gets way out of hand ... once the first set of exercises are out of the way, I usually turn them all loose and let them land their signals wherever their little hearts desire ... but by that time the “basics” are pretty well behind us and they’re starting to learn how to trace the signal flow through the ladder logic ... so a little (lot?) of variety becomes highly educational ...



anyway ... that’s why I used those particular addresses for my examples ... old dog - old tricks ... but your idea of a “self-imposed list” of addresses would be a great idea if I still did a lot of programming out there in the real world ... and I’m pretty sure that the topic has been discussed on the forum before ...

The value to this is the same data will be in the same location from program to program no matter what company or factory you are at. Would save a lot of hunting around.

and that WOULD be great if all we ever had to do was work on programs which we ourselves had written ... unfortunately that is NOT the case ... and so knowing how to “hunt around” and trace through a program and track down the signals is an integral part of troubleshooting a PLC system ... particularly one which uses analog signals and math functions to manipulate them ... but then again, if it was simple then ANYBODY could do it ... and where’s the sport in that? ...



keep us posted on your progress ... your attitude and your approach are impressing all of us ... it’s a pleasure working with you ...

 

[Ron Beaufort]

Greetings Dan,



I had some (rare) extra time this morning and I went back and read this whole thread over again from start to finish ... one thing popped out at me ...



in post #2, Peter said:

So how fast are you updating the PID? You should do this in an interrupt. Hopefully you can do this at 10 millisecond intervals or faster.

I came in later and in post #6, I described the:

“STI” mode (most often required when the processor’s scan cycle is long in relation to the desired PID “loop update” time) ... unless you are trying to control a relatively fast process, then you will probably not require the “STI” mode ...

for some reason or other (advancing age?) I didn’t catch the part that you ARE trying to control a relatively fast process ... and I went on to suggest that you use the “Timed” mode setting for starters and then let us know if you needed a faster update speed ...



now that I’ve read everything that’s going on, I’d like to change my suggestion ... from where I’m sitting, Peter’s “in an interrupt” idea seems to be the better choice ... plus he has a LOT more real-world experience setting up systems like this than I do ...



so think about putting your PID on an unconditional rung in a separate ladder file (specifically, not in Ladder File #2) ... and set the new file up to run as an STI (Selectable Timed Interrupt) ... you’ll probably also need to program (within the STI file) an IIM (Immediate Input with Mask) and an IOM (Immediate Output with Mask) to service the analog inputs and outputs rapidly enough to make the faster PID execution time effective ... and of course your scaling (SCP’s, etc.) should be in the STI too ...



so basically, you’ll be moving (actually Cutting-and-Pasting) all of your PID-related programming into a new ladder file which will execute on a regularly-timed FAST schedule regardless of how long each processor scan cycle takes ... of course the PID “Time Mode” entry must now be set for the “STI” mode ... and very important ... the PID’s “Loop Update” entry must be kept in synch with the STI’s execution setpoint ...



the original approach would certainly serve to get you started ... but eventually (as Peter suggested) you’d probably have to shift to the “interrupt” execution for a final solution ... and in any case, “going faster” won’t hurt anything ...

 

[leitmotif]

Progress

1. Took suggestions -- implemented them. Scaling worked like charm.
2. Using the ORTHODOX Control value worked as well if not better.
3. Went to make a trend - which was a learning experience. Maybe it does not have all bells & whistles of Excel, but it sure makes it easier to see what happens. Took much of evening. Have to get better with it.
4. PERIOD calc'd by time frame of trend and counting peaks came out to 3.3 sec. Is this considered fast??
5. We took PID out of STI - did not seem to make much diff.
but then I probably don't know enough to tell. Will set back into STI and see if there is any difference.

QUESTION
IF I had two inputs such as temp and pressure as inputs to PID which would control one output would I need / use cascade PID.

THANKS

Dan

 

[Ron Beaufort]

1. Took suggestions -- implemented them. Scaling worked like charm.

I love it when a plan comes together ...

2. Using the ORTHODOX Control value worked as well if not better.

by “orthodox” you mean using the “Control Variable” (0 to 16383) for the PID’s output as opposed to the “Control Output CV%” ( 0 to 100) ... right? ... I’m having a hard time just trying to imagine a case where LESS resolution would work better than MORE resolution ... in other words, your results make sense ... suppose that after everything is tuned and running “right” that you go back and retry the “0 to 100” solution again just as an experiment ... I’m betting (pocket change only) that as the load on the system varies, you’ll hear the motor speed “stair-step” from one speed to the next ... with the “0 to 16383” resolution, you’ll probably hear more of a smooth continuous “ramp” effect instead ...

3. Went to make a trend - which was a learning experience. Maybe it does not have all bells & whistles of Excel, but it sure makes it easier to see what happens. Took much of evening. Have to get better with it.

post what you’ve got if you want us to take a look at it and make suggestions ... and this post might be interesting ...

4. PERIOD calc'd by time frame of trend and counting peaks came out to 3.3 sec. Is this considered fast??

pretty fast in the neighborhood I live in ... probably pretty darn slow in Peter’s neck of the woods ...



so how fast are you executing the PID? ... conventional wisdom would suggest something like 330 milliseconds ... personally I like round numbers so I’d try 250 milliseconds and see how it works ... Peter’s 10 milliseconds seems pretty extreme BUT remember that he made that suggestion way back in Post #2 ... this was before we knew anything at all about your system’s characteristics ... even so, 10 milliseconds will still be fine, as long as your processor can reliably and consistently execute the PID that fast ... basic idea: too fast is OK ... too slow is BAD ...

5. We took PID out of STI - did not seem to make much diff.
but then I probably don't know enough to tell. Will set back into STI and see if there is any difference.

with the 3.3 seconds period that you mentioned, I’m betting that the STI isn’t going to buy you any improvement in performance at all ...

QUESTION
IF I had two inputs such as temp and pressure as inputs to PID which would control one output would I need / use cascade PID.

we need more detailed information to answer that one properly ...



but just to get you started, here’s a quick example of basic cascaded control based on the Hotrod ...



suppose that we start out with the Hotrod’s air-flow system ... we wire it up ... calibrate it ... apply a PID to it ... tune the loop ... and now it’s working fine ... the operator dials in a setting of 40% air-flow ... the damper moves to the proper position and it’s 40% air-flow “steady-as-she-goes” ... we turn one of the fans on - and then off ... the PID controls perfectly and regardless of how many fans we have on, the PV recovers nicely ... the sun is shining ... the birds are singing ... life is lovely ...



now suppose that we move on to the Hotrod’s heating system ... we wire it up ... calibrate it ... apply a PID to it ... tune the loop ... and now it’s working fine ... the operator dials in a setting of 200 degrees F ... the heater fires up at the proper percentage and it’s 200 degrees temperature “steady-as-she-goes” ... we increase the air-flow - and then decrease the air-flow back again ... the PID controls perfectly and regardless of how much cooling air we have, the PV recovers nicely ... the sun is shining ... the birds are singing ... life is lovely ...



so far we have two completely independent loops ... independent at least in the way they are being controlled ... but they are inter-dependent in the way they behave ... specifically, the air-flow loop DOES have some effect on the heat loop ... more flow tends to cool the heater and drive the temperature down ... less flow lets the temperature rise ...



next suppose that the boss makes some changes to the way our plant operates ... and suppose that we no longer have the ability to control the temperature directly ... one such scenario might be that the heat is coming into OUR system from some process located upstream of us ... maybe an operation in the plant’s preceding step has left the incoming product hot ... but even though we can no longer just turn our Hotrod’s heater up or down to suit ourselves, the boss still wants us to control the Hotrod’s temperature ...



notice that of the two loops that we’re dealing with, the air-flow is the faster one ... specifically, it takes only a few seconds for the air-flow system to respond to an upset or to a setpoint change and get right back onto the target ... but any such change to the heat loop requires at least 10 to 15 minutes to fully settle down ...



and now we’re ready to talk about cascade control ...



suppose that we leave the air-flow loop alone ... it’s already tuned and running fine ... but instead of having the operator dial in the setpoint (target) for the air-flow system, let’s reprogram things so that now the HEAT LOOP CHANGES THE AIR-FLOW’S SETPOINT ... this is a basic cascade control ...



yes, we’ll have to re-tune the heat loop for this new method of operation, but once we’ve got that done, then as the temperature tries to increase, the heat loop will respond by telling the air-flow loop: “increase the flow - I need more cooling” ... conversely, as the temperature tries to decrease, the heat loop will respond by telling the air-flow loop: “decrease the flow - I need less cooling” ... and so when the upstream process tries to upset our heat-control system by sending us more heat - or less heat - then our two PIDs will work in a cascade mode and allow us to control the temperature in our section of the process ...



now I don’t know whether that answers your original question or not, but that’s my explanation of a basic cascade control system ... maybe that will at least give you some idea of why I can’t give you a better answer without more detailed information ...



glad to hear that things are falling into place for you ... party on ..

 

[leitmotif]

Oh heck if I know what to callit

[/font][/color]



I love it when a plan comes together ...
REPLY yeah especially when it is your own.







by “orthodox” you mean using the “Control Variable” (0 to 16383) for the PID’s output as opposed to the “Control Output CV%” ( 0 to 100) ... right? ...
REPLY Yes

I’m having a hard time just trying to imagine a case where LESS resolution would work better than MORE resolution ... in other words, your results make sense ... suppose that after everything is tuned and running “right” that you go back and retry the “0 to 100” solution again just as an experiment ... I’m betting (pocket change only) that as the load on the system varies, you’ll hear the motor speed “stair-step” from one speed to the next ... with the “0 to 16383” resolution, you’ll probably hear more of a smooth continuous “ramp” effect instead ...
REPLY Resolution is always good, more is better of course. That is good enough for me right there. It would be interesting to see if it did stair step if I went back to what I did originally. Large changes in setpoint resulted in both speed (PV) and COntrol variable changing on a log curve -- no stair stepping and both tracked each other ie stayed fairly parallel.






post what you’ve got if you want us to take a look at it and make suggestions ... and this post might be interesting ...
REPLY Am going to study the Logix software manual. Read the other post (above) - screen displays looked good. If I can export to Excel then I can get Excel file into a post. Apparently both the school and work have just the "read only" version of Win Zip
- at this time Winzip is not an option
- maybe because of operator error.






pretty fast in the neighborhood I live in ... probably pretty darn slow in Peter’s neck of the woods ...



so how fast are you executing the PID? ... conventional wisdom would suggest something like 330 milliseconds ... personally I like round numbers so
REPLY Rockwell said 5 to 10 time faster - if recall correct I picked 0.5 sec.
Little close to upper limit 250 sounds better to me also.

I’d try 250 milliseconds and see how it works ... Peter’s 10 milliseconds seems pretty extreme BUT remember that he made that suggestion way back in Post #2 ... this was before we knew anything at all about your system’s characteristics ... even so, 10 milliseconds will still be fine, as long as your processor can reliably and consistently execute the PID that fast ... basic idea: too fast is OK ... too slow is BAD ...







with the 3.3 seconds period that you mentioned, I’m betting that the STI isn’t going to buy you any improvement in performance at all ...





we need more detailed information to answer that one properly ...
REPLY Well let me try swithc back and see if makes any difference.


but just to get you started, here’s a quick example of basic cascaded control based on the Hotrod ...
REPLY to question on cascade control. I think that answered the question. Deleted the rest to keep this short.

How often do you see cascade control??

Thanks for help.

Dan

 

[Peter Nachtwey]

Less than 1% in motion control. At least the way we do it. Rockwell's 1756-M02AE, 1756-M02As, and 1756-HYD02 all have a velocity loop and a position loop. I think Rockwell's servo motor or drive application would use cascaded loops almost 100% of the time. I do not like cascaded loops unless each loop has a different feedback source. If there is only one feedback for the inner and outter loop then the controller transfer function can be simplified so there is only one loop and one feedback device.

 

[leitmotif]

Data

I think I have the trend figured out - been a few mistakes
BUT
I DID succeed in getting data to EXCEL.

Attached (with flaws) is the Excel versin of the data from the trend in RS Logix.

 

[leitmotif]

Damn where did the file go

 

[leitmotif]

Damn

Damn where did the file go

 

[leitmotif]

I have met the enemy and he is me. The file was .dbf which is invalid extension. So I tried to rename to .xls - that became another horror story. WIll try next week when I have learned more and get better.

Dan

 

[Ken Moore]

How often do you see cascade control??

In the chemical industry Cascading control is very common.

Example:
Reaction vessel has pressure pid as master, with two slave pids controlling flow of reactants to the vessel, as the pressure goes up the flow goes down. The setpoint of the two flow pids, is connected to the CV output of the master pid.

We also move in different tuning parameters to the PID based upon operational modes. For instance the same PID may have one set of tuning parameters when a system is in "heat up" mode, and a different set when in "cooling" mode.

 

[Ron Beaufort]

Greetings Dan,

see if this link will let you download a working copy of WinZip ...

also ... if you highlight some text and then click the little icon shown below, then the text will show up as a quote

like this one

in your post ...