Logix Designer - Ladder PID minimum output odd behavior

rupej

Member
Join Date
Sep 2014
Location
NC
Posts
964
In Studio 5000 Logix Designer, I've noticed some odd behavior of the ladder PID instruction.

Using the .MINO tag, you can set a minimum output for the PID (or you can set it directly in the instruction setup window). If you then set the PID to software manual (.SWM bit) and set the output (.SO) BELOW this minimum, the output will ignore the minimum output setting and go to your setpoint. That part works fine.

When you switch the PID out of software manual and back to automatic, the PID output jumps back up to the minimum output. That also makes sense.

However, the PID appears to continue its output calculations from the manual setpoint below the minimum, which means if the output should be rising based on the calculations, there will be no increase in output until the calculated output rises ABOVE the minimum output setting, which makes the PID appear to be stuck at the minimum for that amount of time. This is similar to an integral wind-up effect on cheap PID controllers.

I did find that once the output does rise above the minimum, the integral calculations are locked such that they can never get "trapped" below the minimum again, which is good.

Has anyone else noticed this and found a workaround? Does the PIDE instruction not have this issue? I've been hesitant to switch to PIDE because most of our customers don't have the function block diagram package for Studio 5000, but if this is going to be a common issue, I may take the plunge.
 
I'm not 100% I understand the issue, but the scenario described raises an interesting point regarding the transition out of software manual (SWM). The behavior described in the documentation is to move the set output (SO) value into the integral term (when I-gain is non-zero) to provide "bumpless" transfer to auto. That is, with no set point error, the output will come entirely from the I term, which being equal to the SO, will not change the PID output on the first scan in auto. (If there is set point error, that will create an output bump.)

In this case, the question is whether the initial load of the integral term is from the manual SO, described as below MINO; or from the output-limited MINO value?

If the problem is a long delay at MINO with positive error, then it may well be the case the I term is coming from the lower SO, which requires time to overcome before output starts increasing. This behavior could be checked by observing the I term in the data table at this type of SO-below-MINO transition to auto.

If this turns out to be the issue, one workaround would be to change the SO to MINO at least one scan before clearing the SWM bit. This would eliminate the extra time to "unwind" the integral contribution of MINO - SO.

It is important to scan the PID instruction at least once in SWM with the desired starting SO. While not clearly documented, my experience is that when SO and SWM change on the same scan, the instruction ignores the new SO, loading the previous scan's SO into the integral term. That is why advise changing SO to MINO for at least one scan in manual.
 
Last edited:
If the problem is a long delay at MINO with positive error, then it may well be the case the I term is coming from the lower SO, which requires time to overcome before output starts increasing. This behavior could be checked by observing the I term in the data table at this type of SO-below-MINO transition to auto.
Yes, I believe that is exactly what is happening. I will verify by checking the i contribution to the output- I didn't realize that you could do that.


If this turns out to be the issue, one workaround would be to change the SO to MINO at least one scan before clearing the SWM bit. This would eliminate the extra time to "unwind" the integral contribution of MINO - SO.
That is a great idea- I will probably do just that. I suppose it would also require logic to check that the manual setpoint is actually below the MINO before setting SO to MINO, or else the output would always bump down to the minimum even when the manual setpoint was much higher.

It's a little disappointing that one would have to add that extra code any time a PID instruction has a non-default MINO or MAXO. I may also try this with a PIDE just to see if it has the same issue or not.
 
The PIDE instruction might not have this issue related to creating a bumpless output on transition to auto because it is based on the "velocity" form of the PID computation which is inherently bumpless with zero set point error. There is no accumulated error term to deal with, in that this form calculates incremental changes in output on each update rather than absolute output.

However, it will be necessary to verify how PIDE applies output limiting in its equivalent of software manual, and what happens at the auto transition if it allows the programmed output to be less than its effective "MINO." And, if so, which one it uses as the starting loop output (meaning it could have the same undesired behavior if using the lesser value). There is not a one-to-one correspondence between the familiar PID instruction data elements and those in PIDE -- at least not all of them -- so the behavior may be different. I have seen forum postings here with helpful mappings between the two, as well as the mode descriptions.

It will be a trade off to decide whether to wrap the PIDE in an AOI to use in a ladder program, or to add the extra logic to deal with this SO-less-than-MINO in software manual issue. One potential benefit is the learning experience in trying to make PIDE work as desired in this application.
 
Last edited:
What happens if the transition to auto is done twice? Once to yank the output back to .MINO, but with left-over wind-up as the OP notes, then quickly back into manual and finally to auto again to clear any wind-up with .SO at (or near) .MINO.


Just an idea; I have no idea if it will work.


It's the PID version of "have you tried turning it off and on again?" cf. https://www.youtube.com/watch?v=Vu5q6EXquuM&t=1m57s
 
Last edited:
Thanks for the help and suggestions, everyone.

So I did verify that the integral calculation is doing a bumpless transfer from the manual setpoint, as suspected.


I checked and it was not set. I tried setting it but the behavior was the same- it calculates its output based on where the manual setpoint was and gets "stuck" until the calculated output rises above .MINO. Was interesting learning what that bit did, though!

Mispeld's solution worked (and drbitboy's would too, I'm sure). I found I was able to add a TOF and it's corresponding .DN bit to keep the .swm bit on for one extra scan after leaving manual mode. There may be a cleaner way, that's just the first thing I thought of.

I'll look into doing the ladder PIDE from PlantPAx on future projects - thanks for the tip, Ken!
 
Last edited:

Similar Topics

Does anyone know how to set the background colors of instuction blocks (TON, MOV, etc)?
Replies
1
Views
92
Hello all, I'm trying to use the Logix Designer SDK to upload and download a single ACD to many controllers. I got this to work fine copying...
Replies
0
Views
44
Hello, I am trying to connect a Stride Analog Output module to a 1769 CompactLogix via Ethernet. I added a new Generic Ethernet Module for the...
Replies
4
Views
180
I see similar questions but not exactly what I’m looking for in the history. But my problem is…. I’m trying to upload a program from a 1769-l33er...
Replies
21
Views
449
Searching edit zones within all routines and other criteria still says no results found, yet I still have the "edits present" indicator at the...
Replies
6
Views
241
Back
Top Bottom