Studio 5000 PID Issues

jds8086

Member
Join Date
Jan 2020
Location
Kansas
Posts
42
In this routine, i have an issue where when "lineSpeed" is changed, the PID loop math does not appear to be working out correctly and if I'm only using KP, it will never remove the error, it will be off by some amount and even though the calculated bias appears to be correct. What seems to "fix" it every time is to simply open the PID Setup, then click OK. So it appears something is not "updating" that needs to but i can't seem to track it down.

3adk3.PNG
 
1) this could be the same problem as the other thread


2) what is the update time parameter setting in the PID?


2.1) How often is the displayed code executing?


3) Kp-only control will always have an offset of PV from setpoint, except at nominal conditions.*

* update: it appears the PID is controlling speed to minimize position error, so there an integral action on the process, so that statement 3 might not be correct on this particular case.
 
Last edited:
N.B. the (catSpeed - lineSpeed) term in the CPT on rung 1 can be replaced by catSpeedModifier, which may yield a slight reduction in roundoff error of verticalSpeed, but will not help significantly with the roundoff error in rung 2.
_
 
Last edited:
If pid.Ki and pid.Kd are indeed 0, so it is Kp-only, then the PID update time does not matter, although that also means the PID is nothing more than a linear filter i.e.
CV = Kp * (.SP - .PV) + .BIAS
similar to Rung 2, and it appears that Kp ~ 1, so
CV ~ (.SP - .PV) + .BIAS​
plus whatever CV-to-EU scaling is in effect.
 
If this is not CompactLogix 5x70, then convert everything to LREALS e.g. the CPT expression on Rung 2 would be
L_festoonPosition + ((L_catSpeed - L_lineSpeed) * L_MTPRE / 60000.0L)
Where the tags with a prefix of L_ are all LREALs, and there is a
MOV masterTimer.PRE L_MTPRE
instruction somewhere.

The P-only PID could be replaced by a CPT with expression
L_CV = L_Kp * (L_SP - L_festoonPosition) + L_Bias

 
It appears that changing festoonPID.MINCV (and presumably any of the scaling factors) has no effect until the PID is initialized(re?). I noticed that clicking the "PID Initialized" checkbox in the scaling tab of the PID setup would also make things work correctly after a lineSpeed change. I looked into this bit and found the following (see attachment). I have added some logic that will toggle this bit when lineSpeed != lineSpeedLast. I am now able to change the line speed and have no issues with things "tracking".




See publication 1756-RM003W-EN-P - March 2022, page631
 
As always, and in agreement with janner10, put the PID instruction (that's all you need to do) into a periodic task. Don't forget to write the update period into the .UPD parameter of the instruction's tag.

When you've done that, you can start to investigate your issues, but if you don't, you won't see the wood for the trees.
 
As always, and in agreement with janner10, put the PID instruction (that's all you need to do) into a periodic task. Don't forget to write the update period into the .UPD parameter of the instruction's tag.

When you've done that, you can start to investigate your issues, but if you don't, you won't see the wood for the trees.


Did you see my post (above yours), i found the problem.


As far as placing the PID instruction into a periodic task, can you explain what effect the UPD parameter has vs placing it into a periodic task? I assumed (wrongly it seems) that the whole purpose of the UPD parameter was to set the frequency that the loop is updated.
 
You dont have to use periodic task. A free running timer and set loop update time equal to free running PRE.
Another way is to use the analog card timestamp values.
 
You dont have to use periodic task. A free running timer and set loop update time equal to free running PRE.
Another way is to use the analog card timestamp values.

Every other way of triggering the PID calculation is going to introduce "jitter". For best results, put your PID instructions into a relatively high-priority Periodic Task, Fit and forget, and don't worry about other code mesmerising your scan times.

The PID instruction is the important thing, it definitely needs to know the time elapsed since its last set of calculations for best results of what to do next.

There are things you cannot do "real-time". Analog inputs and outputs will have a latency, so will your code to manipulate what goes where and when, but will not introduce anywhere near the inaccuracies a PID that calculates on the wrong time interval.

Let PIDs calculate with the best information they can get, and they will perform ....

What could be simpler ?

If you don't like it, try the PIDE instruction instead ...
 

Similar Topics

I'm setting up a PID for a 50hp RO pump in a water treatment plant. When I go to manual mode on hmi I set the swm bit, I also ons the pid output%...
Replies
5
Views
524
Hi All, I'm using Studio 5000 ver 30 to modify existing logic that has PID, and I want to be able to use an external/remote source as a setpoint...
Replies
3
Views
607
It is now an add on license option for $ 713 After a week of nobody @ Rockwell being able to tell me why my Auto tune was grayed out... I...
Replies
33
Views
10,925
Does anyone know of any sample code for an analog process simulator? I'm looking to test out some PID tuning methods but would rather have the...
Replies
26
Views
7,517
PLC is a 1769-L30ER PID instruction. Setpoint = 26687 PV = 13537 Control Action = SP-PV. Error should = 26687 - 13537 = 13150 Error listed...
Replies
1
Views
1,452
Back
Top Bottom