PID Instruction question

[PasTech 1]

I know, another PID question. Forgive my rehash, but please bear with me. I have read some very good material on how a PID instruction works on this forum and other places, Ron Beaufort's material in particular, that have helped me a lot. I also have (or now, had) the same misconception about the "Loop Update Time" parameter a lot of people have/had, wondering why even Mr. Beaufort would only say the PID needs a timer to trigger it ......"because the PID is like a blind accountant locked in an office without windows ... he can't see a clock or a calendar – so the only way that he knows precisely when it's time to calculate a new CV value is when your program "triggers" him into operation ... " The part I put in bold was the clue I didn't quite get. It wasn't until I saw this from forum member daba in a 1 year old thread that the correlation was made: " Remember that the PID instruction just performs a calculation every time it is scanned. That calculation will include factors that are time-based (integration and derivation), so the instruction needs to know the time interval since it was last scanned to give good results." We have to tell the instruction what the time interval is, and we do that via the "Loop Update Time" parameter. Now I get the connection. DUH!! Like Mr. Beaufort says, all students are not created equal. Different things work for different people. In my case, it was seeing both of those statements in the same post. To get closer to my question: I have inherited a number of programs containing PID controls, mostly for maintaining pressure, written by "experts" whose PID instructions are unconditional. They are triggered every scan, but triggered by the scan and nothing else. These instructions also have "Loop Update Times" ranging from 1 second to 10 seconds. It would appear that the experts in this case didn't/don't understand PIDs either. So now my question: What will happen when I install a timer trigger and match the "Loop Update Time" to that trigger? My prediction is that the loop may actually slow down since the calculations will now have an accurate number to base on, not using 10 seconds when in reality only a few milliseconds have passed. I have a pair of stand alone systems I can test with, one a Compact Logix (the only one I have), the other a SLC (what all the rest are). Thoughts? Am I close? Way off? I will head for the Compact Logix site this morning and will check back here for your thoughts. TIA

[Guest]

why can't I Paste into the "Reply" window? ... I've typed up quite a long answer in Word - but suddenly I can't Paste it in ... Ron

[Guest]

let's not be too hasty here ... what platform are these unconditional PIDs being used in? ... if it's one of the RSLogix500 platforms, then an UN-conditional rung is USUALLY the right construction to use ... that's because the PID for an RSLogix500 platform has something very much like a "built-in" timer which can be used to "trigger" the PID on a timely basis ... here's more of what we need to know in order to nail this down ... what software are we using? ... RSLogix5, RSLogix500, or RSLogix5000? ... if it's RSLogix500, what is the PID's "Time Mode" setting? ... if it's set for TIMED, then the PID is using a "built-in" timer which will automatically take care of the "triggering" action for you ... but if the RSLogix500 has a PID with a "Time Mode" setting of "STI" then that's a different situation ... in that case, the built-in timer will be disabled and the PID will indeed be executed on each and every scan ... so ... in that particular case, the PID is supposed to be programmed into an STI-type file (Selectable Timed Interrupt) ... the STI file only executes based on a setting which tell the processor how often to execute the STI and thereby the PID it contains ... in that case, the "Loop Update" is supposed to match the STI setting ... if the software is RSLogix5000, then the PID instruction MIGHT be correctly programmed on an unconditional rung as long as that rung is located in something like a Periodic Task which would take care of the "triggering" operation ... if the software is RSLogix5, then the PID instruction MIGHT or might NOT - be correctly programmed on an unconditional rung depending on whether the PID is using an Integer-type Control Block or whether it's using a PD-type control block ... even from this short discussion, it should be obvious that when it comes to PIDs, one size does NOT fit all ... so ... here's a question for you ... are you allowed to post the program files for the systems that you're working on? ... if you can do that, then it will save a LOT of confusion and we'll be glad to take a look and try to help you sort all of this out ... the main idea: just because it "looks wrong" doesn't necessarily mean that it IS wrong ... so move cautiously ... the old saying "if it ain't broke don't fix it" comes to mind ...

[Guest]

that's WEIRD ... I just found a "Theme" setting - and changed it to "mobile" - and now I can paste ... but I'm NOT using a mobile device - and never have ...

[PasTech 1]

Thank you, Ron, for responding. I didn't mention what software was in use as I thought mentioning the one Compact Logix and multiple SLCs was enough. That's what I get for a long post. And of course this one is longer. I work for a county utility and have 7 waste water treatment plants, 5 water treatment plants, and 6 pump/booster stations. One of the pump/booster stations is the Compact, so RSL5000. Everything else is SLC 5/05 for pressure, so RSL500. The 7 waste water plants also have an SLC 5/04 at each plant controlling chlorine dosing. Tough process for a PID to control (long time between dosing and sample measurement), but it seems to work OK. Based in large part on what I learned from the information you have published, I have reduced Chlorine usage, so my thanks to you, Ron, for the education. As for "if it ain't broke...." I agree wholeheartedly. I am, however, working on complaints of pressure dips and spikes they have been just living with for years. They have recently come close to blowing some customer equipment out the ground (literally), so now I get to look into it. I'm seeing a good bit of overshoot/undershoot, and they ALL go to 100% very quickly when started with pressure below set point. I get that pressure should come up fairly quickly, but 0 - 100 in 3 seconds is the type of response one wants in a super car, not a water pump. Especially if you don't want to damage someone else's equipment. The response times are also quick and too much, resulting in the overshoot/undershoot I mentioned (I'll start with gain here). I expect some of these just need a little tuning and finding that happy medium. I have been spending so much time on the Compact Logix PID as it is on a time crunch that the "Time Mode" parameter got away from me. Working on one of the SLCs at the end of my day yesterday, I came across that mode while trying to fix the 0% output that resulted when I tried to trigger that PID with a timer. That program does not have a STI file but the PID is in STI mode. As I said, it was the end of the day, so I just removed the timer bit. I'll get back to it. I thought I had seen the STI file in a couple of the programs, but they were empty. Not understanding what they were and they were empty, I likely deleted them, but that has been some time ago. Checked some of the PIDs for "Time Mode", and they are in STI mode. So if the mode needs to be "Timed", what sets the trigger? "Loop Update" parameter? If I just relocate the PID to a newly created STI file, set the time in Processor Status>STI? Looks similar to setting up a Periodic Task in RSL5000. I will attempt to attach the SLC I was working on yesterday with this post. This one is a now offline waste water plant whose ground storage tank is now fed from the county-wide reclaimed water system instead of the plant, and it's pumps now feed a customer directly. The customer used to be fed from the main system, but the pressures were inconsistent. When the waste water plant came offline, they reconfigured the system there and re-purposed the pumps. They no longer pump into the main system from that tank. They don't use tank level mode, only pressure mode. The PIDs for level and pressure control are in LAD 4. All of the SLC 5/05s in the waste water plants were programmed by the same outfit at the same time(ish), so they look like copies of each other, with some minor differences in the equipment on the plants and extra things they decided to add to the "new" PLCs (this was an upgrade to provide reclaimed water county-wide 10-12 years ago). As for the Compact Logix, the PID is now in a periodic task and is working MUCH smoother. FAR more controllable ramp up and response times. VERY happy with that one now. Thanks again Ron and MrPLC Forum. It's a new pump station to supply reclaimed water to a grove, so I can only test for so long. We are close to doing a live test, but I am now confident it will go well, other than my concern that the pump and pipe sizes may fall short. Low bid can be a real pain. Especially when finance thinks they do a better job of determining what we need, but that is another rant. Looks like the attach was successful. It's only taken 2 hours to write this. Too many interruptions. Thanks for the feedback. Jim HUDSON_Joe.RSS

[PasTech 1]

It appears some are still looking at this, so I'll try here first. I've created a test program in a SLC 5/05. Just a few rungs in LAD2, the STI is in LAD3 along with the PID. STI parameters are set for 1000ms and file is set to 3. STI executes once and faults the processor: Invalid parameter in PID. Parameters in PID are programmable offline, but everything is 0 online and will not change. What am I missing?

[PasTech 1]

Gotta love these things. Started working after I lost comms (cable pulled out of laptop) then reconnected. Using the RS232 port.