PIDE - selecting "Control States" and "Operation Modes"

[Guest]

Greetings to all ... this post is basically an answer to a question which was recently posted on another forum ... I’m posting the answer here because MrPLC.com doesn’t have a “statute of limitations” on editing - and I’m probably going to need to “fix” things along the way ... the original question (basically) relates to some of the setup parameters involved in the PIDE instruction for RSLogix5000 ... this instruction uses Function Block Diagrams - and has (for better or for worse) a LOT of bells and whistles ... I’ve been tinkering around with the PIDE instruction for a while now in my spare time - but suddenly I’ve got a customer flying in from Texas in a couple of weeks for a class ... his program uses the PIDE quite heavily - and I’ll need to cover it in quite some detail ... plus his plant’s program is still being written - and there are a lot of “loose ends” involved in the copy I’ve received ... naturally this will all be cleaned up by the programmer - but in the meantime, I’m going to have to cover a lot of “extra” stuff in the class that probably won’t even be used in the final version ... so be it ... anyway ... here is a quick sample of my take on “how the switches work” to select the OPERATOR STATE and the AUTO MODE setting for the PIDE ... this and the other configurations are shown in the .PDF file attached below ... like most of the drawings that I’ve developed for my classes, the page isn’t really intended to be an “explain it all” treatise ... it’s more like a “lab exercise” worksheet - suitable for the students’ lab notes to be written in the margins ... and here is a “rough draft” of an RSView32 screen that I’ve been using to manipulate the settings - and monitor the results of the various configurations ... I’ll probably clean this up a little and let the students use it to control the PIDE during their lab exercises ... my main reason for posting all of this is to get some feedback from anyone who’s interested - specifically in the area of “is this broken down enough for a student to understand?” ... I’ve had the same types of charts, etc. for PID in the PLC-5 and SLC-500 platforms for years ... those have always worked fine ... but then again, those platforms don’t have TWO “control states” and FOUR “operation modes” to contend with ... now add in a handful (about eleven) of extra “ProgOperReq” type controls - and some “CVProg” and “CVOpr” settings - etc. - and things start to get a little fuzzy around the edges ... personally, I’m pretty sure that I’ve got it figured out enough for my own use - but I’m trying to present it systematically enough so that the students will be able to understand what’s going on ... naturally the “official books” don’t have any suitable “flow charts” like this (or at least I haven’t been able to find any) ... basically I’ve just experimented with all of the various combinations of settings until I now feel comfortable with how they work ... as I said, I don’t expect anyone who isn’t already familiar with the subject to be able to “pick up the ball and run with it” after just looking over this “cheat sheet” type material ... all I’m hoping for is that the basic layout is clear enough to show how the “mode bits” are used to select the desired signal flow through the PIDE block - and to make some “side-by-side” comparisons to how the different modes work ... once the class is over, the students should be able to use this handout material to analyze the settings used in their programs back at the plant - and systematically track down “what comes in” and “what goes out” during their troubleshooting sessions ... disclaimer: a lot of this work was lubricated with midnight oil ... I “think” that I’ve got it all right - but a typo here and there would NOT surprise me ... your efforts at proofreading will be highly appreciated ... so ... if anyone has any constructive criticism - or suggestions for improvement - please feel free to comment ... final note to buhnen (the original poster) ... I hope this material helps answer your question ... thank you for providing the incentive for me to finally get it all nailed down ... PIDE_States_Modes.pdf Edited 8 Jul 2008 by Ron Beaufort

[Guest]

another piece of the puzzle ... how to actually select the PIDE's "Control States" and "Operation Modes" ... the .PDF below shows "truth table" type charts for setting the appropriate "Request" bits ... note that "don't care" conditions are marked with "X" characters on the charts ... once again, this is not the final format ... I ran out of midnight oil before I got everything lined up properly - but I think that the data is correct ... (I'll check for typos once my eyes open up again) ... note that the "highest priority" requests are located at the top of each chart - "lowest priority" requests are located at the bottom ... so for examples: a request for "Hand Mode" (highest priority) outranks any other request ... a request for "Auto Mode" (lowest priority) won't work unless all other related "mode request" bits are turned OFF ... PS Edit ... the .PDF attachment was updated slightly on July 10 ... just a few words of text were added ... nothing that changed the basic information involved ... Select_State_and_Mode.pdf Edited 10 Jul 2008 by Ron Beaufort

[paulengr 44]

One of the supposed features of the PIDE instruction is the built-in autotuner. I didn't see that show up in your diagrams. Is this yet another state/mode?

[Guest]

Greetings paulengr ... it's "built in" as an extra-cost option ... the latest package of RSLogix5000 (version 16) that I purchased was the "full" version - but not the "pro" version ... I haven't had time to dig through everything that I bought yet - but I don’t expect the autotune function to be in there ... that means I won't get a chance to play (I mean "work") with it until I decide to spend more money ... that probably won't ever happen - because the PID classes that I teach are intended for maintenance technicians - rather than for process engineers ... so learning to use an autotune feature isn't really high on the list of priorities ... instead we spend most of our time on connecting the inputs and outputs - calibrating them - scaling them - troubleshooting them - then on how the PID gets shifted from one mode to another - how the HMI ties in - and more along those same lines of "maintenance-technician-get-the-system-working-again" type stuff ... we DO cover several manual tuning exercises on the Hotrod trainers - but the main objective is to visually recognize the differences between a “properly tuned” loop - and one that “something” has changed into an “improperly tuned” loop ... basically: how to recognize the patterns in those squiggly lines on the screen - and the differences between “good” lines - and “bad” lines ... keeping the course objectives in mind, being able to just push an “autotune” button would be detrimental to the learning experience ... now someday a new customer might pop up who really wants to cover the autotuning feature ... when (and if) that day ever arrives, I’ll have to call up my friends at the local Allen-Bradley distributor - and pay for the extra-cost “built-in” feature ... but while we’re on the subject ... many years ago, while working for a tech school, I ran into a guy who was unimpressed with the fact that the “great big” Allen-Bradley PLC-5 we were using didn’t have an autotune feature - but the little bitty (matchbox size) single loop PID controller that his company used (I think it was Omega brand) DID have an autotune feature built right in ... anyway ... he brought one of the little controllers in one night, and we connected the PV and CV signals to it ... we left the PLC-5 in control of the rest of the system (fans, pumps, etc.) but propped the little bitty controller up on a couple of books and let it handle the PID heating loop ... after we did the autotune trick (it did a “fair” but not spectacular job) we pulled out the values of the Proportional, Integral, and Derivative parameters - and plugged them into the Allen-Bradley ... bingo! ... the response was the same ... moral of the story ... IF (big IF) I really needed to do “autotuning” on a regular basis, I’d probably check into how well the performance of the extra-cost option would stack up against the capabilities of one of those little bitty controllers ... I mean - once you’ve got the tuning values, that’s all you really need - unless, of course, something “goes wrong” and changes the system dynamics ... in which case, you’d probably need to fix that “something” - rather than just retune the system ... sure, I’ll admit that the “temporary controller” approach isn’t going to be nearly as quick and convenient as just pressing an autotune button on the HMI - but if all you need is a set of “close enough” numbers to plug in, the method might be one way to get them ... come to think of it, I don’t believe that I’ve ever seen that idea discussed on the forums before ...

[Guest]

Greetings to all ... I just got this as a Private Message from our new friend buhnen - who's having a problem posting a question in this thread ... you have every right to be confused on this part ... the reason that the CV value is “linked back” to the CVOper location during Auto Mode is to prevent a “bump” from occurring when the system is eventually switched back to the Manual Mode ... explanation: suppose that the system is running in Auto Mode ... suppose that the Setpoint (target) is 40% ... suppose that the PIDE math is computing a CV (output) of 65% ... suppose that this 65% output is perfect – and so the PV (input) is running along perfectly on target at the desired 40% ... the sun is shining ... the birds are singing ... life is lovely ... now pretend for a moment that the CV (output) is NOT being “linked back” to the CVOper location ... and suppose that the CVOper location contains a very low value – something like 10% just for example ... now suppose that the operator decides to switch the system into the Manual Mode ... when this happens, the CV (output) will suddenly and immediately shift from 65% all the way down to 10% (the value stored in the CVOper location) ... the effect is what some programmers call a “bump” to the system ... now in some systems a “bump” like this might not be a big deal at all ... but in some other systems it could be disastrous ... a lot depends on the type of system being controlled – and on how big the “bump” happens to be ... now then ... notice that in the OPERATOR STATE – AUTO MODE example in my previous post, the CV (output) IS being “linked back” to the CVOper location while the system is running in the Auto Mode ... and now you should understand why ... basically it’s because when the system is eventually switched into the Manual Mode, the CV (output) will be able to “pick up” right where it left off ... and now the operator can slowly adjust the value in the CVOper location as desired ... important point: the fact that the value from the CV (output) is being “linked back” to the CVOper location has NOTHING to do with actually controlling the system while running in the Auto Mode ... specifically, the value is just being “stored” in the CVOper location FOR FUTURE USE – when (and if) the system is switched into the Manual Mode ... now for the CVProg location, we have a little more control over the operation ... here we can program the system to either “link back” or to NOT “link back” the CV (output) value into the CVProg location ... as you noticed in my chart, by turning the bit ProgValueReset ON or OFF we can control whether the “link back” feature will be used - or not used - for the CVProg location ... going further ... if I were you, I wouldn’t worry too much about the terms “PROGRAM STATE” and “OPERATOR STATE” – at least in the beginning ... in most cases, the terms DO make sense ... but ... when you really get right down to it, there is nothing to prevent you from programming the operator’s HMI to place a value into the CVProg (program) location – just the same as placing a value into the CVOper (operator) location ... specifically, the PIDE isn’t going to know (or care) which of those two locations is being fed from the operator’s HMI – and also, the PIDE isn’t going to know (or care) which of those two locations is being fed by the logic in your PLC program ... but – a warning ... doing “weird” things with the program might make it harder for other programmers – and other technicians – to understand what you’ve written – but the PLC processor won’t care how tangled a web you weave ... secret handshake: while you’re trying to learn how this PIDE thing works, it might be helpful to mentally drop the terms “PROGRAM STATE” and “OPERATOR STATE” and just temporarily consider the two conditions to be “STATE A” and “STATE B” – or something along those lines ... specifically, it is OK for the PROGRAM to write values into the OPERATOR’S memory locations ... and it’s OK for the OPERATOR to write values into the PROGRAM’S memory locations ... as you gain more experience, the distinction between the two states will start to fall into place ... the main point that I’m trying to make is that you shouldn’t let the NAMES of the locations needlessly confuse you ... just try to learn how the various signals affect the operation of the system ... don’t get too hung up on the names of the locations ... the best way to proceed is to decide “THIS is how I want the system to react” – and then work through the available controls and features to make the system perform the way you’ve specified ... but ... certainly there is NOTHING wrong with experimenting with ALL of the various settings – just to see what’s available ... and that’s really the best way to learn ... hopefully the charts that I’ve been posting will give you some insight into “which” signal goes “where” – and also what bit patterns are necessary to make those signals move ... finally ... once you get the system to work EXACTLY the way you want it to, don’t forget to “power cycle” the system in ALL of the available modes that you’ve programmed ... specifically, just because everything works PERFECTLY while the power stays on, doesn’t necessarily mean that the system will always shut down and then power back up in a safe and predictable manner ... quite frankly, you should lose a few hours of sleep worrying about situations like that ... I hope this has been helpful ... good luck with your project ...

[buhnen 0]

Thanks Ron for this great lesson about the PIDE settings. I can say now that the Light has popped up in my mind to understand the "mysteries" of the PIDE I've been recently hired by an engineering company involved in automation and control for water purifying plants systems (amongst other fields) and PIDs applied to flow regulations will be part of my "daily bread" so it worths to spend some time and effort on learn as much as I can on PID's Thanks a lot! Edited 11 Jul 2008 by buhnen

[buhnen 0]

Hi again Ron, Some months ago I had the pleasure to get some very useful explanations from you about some facts regarding the PID programmation using the PIDE block in AB. Now I'm re-reading again all of them since I'm going to start with my first real case of PID programmation (I've posted the details of this issue in a new thread called "My first PID programmation in ABradley") As you very well explained the reason why PIDE_01.CV and PIDE_01.CVOper must be linked between is for avoiding what is called "bump transfer" when you shift Auto to Oper. So far I've understood this strategy: The last CV value used in Auto mode is the first one the system works with when you inmediatly switch to Manual. Ok, and here comes my new doubt: What about when you do the opposite? I mean, What about when we shift back Manual to Auto? For instance if in Manual I've chosen a value of 30% for the CV and when shifting back the PID algorithm has determined a value of , let's say. 70%.....wouldn't happen here again that bump we want to avoid? Please I need some light about this issue. Thanks in advance for your time to read this.

[César Nunes 0]

On 09/07/2008 at 1:51 PM, Guest said:

another piece of the puzzle ... how to actually select the PIDE's "Control States" and "Operation Modes" ... the .PDF below shows "truth table" type charts for setting the appropriate "Request" bits ... note that "don't care" conditions are marked with "X" characters on the charts ... once again, this is not the final format ... I ran out of midnight oil before I got everything lined up properly - but I think that the data is correct ... (I'll check for typos once my eyes open up again) ... note that the "highest priority" requests are located at the top of each chart - "lowest priority" requests are located at the bottom ... so for examples: a request for "Hand Mode" (highest priority) outranks any other request ... a request for "Auto Mode" (lowest priority) won't work unless all other related "mode request" bits are turned OFF ... PS Edit ... the .PDF attachment was updated slightly on July 10 ... just a few words of text were added ... nothing that changed the basic information involved ... Select_State_and_Mode.pdf

Hi there everybody. I'm working with the PIDE for a few weeks now and I'm with some trouble on understanding how this block switches between the operating and control modes. I imagine this PDF would help me a lot to get through this issue, but unfortunately I can't download it. Anyone could send it to my e-mail please? The address is "chtnunes@gmail.com"

Edited 21 Sep 2016 by César Nunes

[androcci 0]

is this post dead? what happened to the PDF?? :( 

 

I would like to see as there is al to of confusion between operator and Program states.