SLC 5/05 PID Time Mode Question

I am supporting someone elses PLC logic at a Pharmaceutical site, the System is validated and is not easily changed. One of the PID loops is configured to use a STI time mode, however there is no STI configured to run. The loop update is set to 0.25. What is happening? I do see control, but it can be unreliable. Can I leave it as is or should I Fix it. I am not certain how it is working at all, it must be basing off of scan time I guess.
Any info would prove useful.

If you don't like validation, stay away from the pharmaceuticals

If you see the PID in STI mode, then the PID instruction should be in the STI. Since there is not one, it is being updated every scan, and using 0.25 as the dt part of the equation:

Out = K_c((E) + (1/T_i(Œ E)dt + T_d(∆E/dt))

where E is error.

Just how "bad" this is is going to depend on your scan time. If it's close to 250 msec (which would be huge - you must have a lot of JMP-LBL instructions), then you **COULD** change it without changing anything else.

If your scan time is slower, then in order to "fix" this, you are going to have to adjust T_i and T_d by the ratio between your scan time and 0.25 in order for the loop to behave the same.

I said you **COULD** do this. Before you do, you are going to have to follow the pharamaceutical's change control procedure. Although this will vary with pharmaceutical companies, it will problaby be something along these lines.

1) Fill out a change request. This will document the observed problem (i.e, how it affects the quality of the stuff you're making), and the proposed solution. You will also need to identify in which documents (Functional spec, Design spec, Module specs(if any), and especially SOPs) are affected. You will also need to explain which other systems this change is going to affect - what system use the PID or the thing that it controls. You will also need to describe how you are going to test this change (Expected results)

2) Submit the change request for approval. Usually this is about 6 signatures: engineering, quality, validation, production, mainentence& safety. Realizing that:
a) none of these people understand what you are talking about regarding STI vs. Timed in a PID block;
b) this is not a priority for them;
c) at least one of them is almost always in some meeting or other.
Getting approval can be a 3-6 month process.

3) Execute the change. Remember that you will need to test the results to see if they worked, and show, to the best of your ability, that there are no interactions with any other systems. And of course, validation will need to be involved in the testing (see above crack about meetings).

---

Of course, the reality is that no one is looking, right? No one will know you made the change, right? It's just a stupid PID loop ferkrysake!

Chances are that you're right, and you won't get caught. There is a chance that something that you didn't think of (like needing to retune) will affect the quality of what you're making. If so, and if something bad happens from that (like someone DIES), then someone will compare the copy of the code that's on file with the one that you altered. And if they find that you broke validation rules and make an unauthorized change....well, if you're lucky, you simply will just find yourself unhirable in the PLC field.

So you gotta ask yourself, kid. Are you feeling lucky?

If I were you, I wouldn't mess with it unless you are running out of range on your Ti and Td values OR your control is getting unstable. Like Allen said, at the vary least your Ti and Td will need to change by the ratio of the actual scan time to the current configured STI time. But what you are ultimately doing is performing a scaling. So if you are just looking to make it more understandable I would wait. You might be able to wrap this correction in with a future change that is required.
The one exception to this is if your scan time is so variable that the output response is very unpredictable. Also, with the relatively short dt (in plc terms) you may have the tendancy to amplify noise on the process variable to a greater degree than the longer dt from the STI would. This would show up as intermittent 'blips' on the control variable.

Keith

I'll bet that there's more to this than meets the eye ...

Greetings Dwarfer1,

I agree with everything that my distinguished colleagues Allen and Keith have already posted ... I would add the following ...

is it ... or is it NOT ... your responsibility to at least report this discrepancy now that you’ve found it? ... note that I’m not debating the point ... I’m just asking a simple question ... your answer to that question should help you make up your mind whether to just “look the other way” and get on with your life, or to at least report this mess so that someone can decide what to do about it ...

in your own words:

I do see control, but it can be unreliable.

Click to expand...

this sounds like the type of thing that could come back to bite you (personally) someday in the future if you do NOT do “something” about it ...

next point ... I’d strongly recommend that you post the PID rung and the rungs which take care of scaling the PV (Process Variable – input) and the CV (Control Variable – output) of the PID ... reason: when we see the type of “timing issue” that you’ve already described, there are USUALLY other problems in the PID programming also ... think: suppose that you report the “timing issue” and then jump through all of the hoops to get it fixed ... do you want to go right back again and fight the same battles for another “gotcha” that the original programmer left behind? ...

anticipating your likely response: “but it’s proprietary code and I can’t post it” ...

maybe so ... but at LEAST tell us what the PID’s tuning values (Kc, Ti, and Td) are set for ... I’ve got a sneaking suspicion that we’ll have some more to talk about once you post that information ... and how about the “RG” bit? ... is it off or on? ...

if you have no problem posting the code, then I’d suggest that you post the whole .RSS file ... we’ll be glad to take a look at it for you ... five bucks says that there will be other “issues” in there too ...

and finally ... welcome to the forum ...

Thanks for the advise on this. I am very aware of the validation issues and have already reported that I have seen an issue. Obviously the company is looking for input regarding the severity. I have only had verbal comments about the control, hence I looked into the code.

I have also spotted, as you guessed quite a few additional issues, and am currently going through about 42 Change Controls already, this was just the latest item I spotted.

My guess is that after a risk assesment the company will want me to set the PID to be in timed mode, and not set up the STI.

I would also add that in the Pharmaceutical area, I would always communicate control issues I see, you can never tell exactly what the impact could be on a drug process.

Thanks all.

Greetings Dwarfer1,

... the company is looking for input regarding the severity

Click to expand...

please keep in mind that the severity of this problem could be quite erratic and intermittent in nature ... as Allen pointed out, the PID is being executed on an “each-and-every-scan” basis ... as long as the processor’s scan time stays relatively consistent (from scan to scan) then any adverse effects on your PID’s ability to control will be minimal ... but if the scan time fluctuates appreciably (sometimes longer – sometimes shorter) then the PID will react (basically – see disclaimer below) as follows:

for the Integral component ...

when the processor’s scan time is LONGer, the contribution from the PID’s Integral component will be DEcreased from its expected action ...

when the processor’s scan time is SHORTer, the contribution from the PID’s Integral component will be INcreased from its expected action ...

for the Derivative component ...

when the processor’s scan time is LONGer, the contribution from the PID’s Derivative component will be INcreased from its expected action ...

when the processor’s scan time is SHORTer, the contribution from the PID’s Derivative component will be DEcreased from its expected action ...

note that the effect of using “scan time” to trigger the PID (basically) causes the Integral action and the Derivative action to respond in OPPOSITE ways ... specifically when one action is INcreased, the other action is DEcreased ...

additionally ... IF you are using Derivative action, the “each-and-every-scan” execution will often adversely affect the Derivative component’s “filtering” action ... this usually results is an extremely “jittery” response from the Derivative which, in turn, often makes the CV very erratic in nature ...

the main thing to keep a watch on while the company is “looking for input regarding the severity” is to make sure that the testing takes into account the fact that the processor’s scan time might be highly unpredictable ... it is conceivable that the system could be monitored for a very long time without noticing any serious impact on the PID’s ability to control ... BUT ... there could be issues in your program which could suddenly either increase or decrease the processor’s scan time at some point in the future ... if that were to happen, then the system could suddenly react in a manner which the previous testing and monitoring had failed to predict ... specifically, a system configured in this manner could suddenly become “detuned” by (for one example) something as simple as just adding in some additional programming code to the existing program ... one “bad case” scenario: the programmer adding in the new code might have no reason to suspect that the PID loop suddenly needs to have its Integral and its Derivative settings “retuned” in order to give the same response as it did before the program change ... if no one notices the PID’s sudden “poor control” then bad things could certainly happen ...

now ... a disclaimer ... most of the information above is “general” in nature ... since we can’t examine your program or your process, the best that we can do is to offer this type of “basic” information and hope that it will be accurate enough to help you out ...

finally ... you said:

I would also add that in the Pharmaceutical area, I would always communicate control issues I see

Click to expand...

I certainly didn’t mean to imply that you wouldn’t ... I was only trying to help you focus your thoughts on the real issues ... specifically:

1. this needs to be fixed ...
2. it needs to be fixed in the right way ...

after all, you did ask:

Can I leave it as is or should I Fix it.

Click to expand...

we’re all pleased to see that you’re obviously taking the correct steps to handle this situation ... please let us know if there’s anything else that we can do to help ...

One more thing to consider...

It's possible that the bit that's set isn't the cause of the intermittant erratic behavior.

It's possible that you simply have a badly tuned loop. There should be an SOP for the maintenace department on tuning this loop.

Part of OQ and/or PQ (Operations Qualification / Performance Qualification, for those who don't do validation for a living) is to establish the window that the system can be run to get a quality product.

There should also be a PM cycle for the maintenance department for that machine, which should (one would hope) include retuning. If they retune, then the bit could be flipped at that time, and there would be no violation of validation rules, as the value of that bit is no less significant that the values of K_c, T_i, or K_d.

Hi To all,

Unfortunately all of the tuning parameters are open to the customer, albeit under restricted access, so poor tuning is certainly possible, lots of super keen engineers out there with a very basic knowledge of cause and effect. However the loop exhibits occasional bad stability, and with the current tuning a quick test that fixed the timing seemed to improve the situation greatly. Since the Scan time in the code can vary significantly depending on what functions are being called it does make sense.

The customer has decided that with the number of changes required they are willing to allow some significant surgery in the PLC code, SCADA, and additional Vb modules. They are also requesting additional functionality 3 years after the code was written, as they are only just starting to operate the systems.

Looks like it is going to be a long Christmas.

Thanks again Guys.