PID tuning woes

[drbitboy]

WHAT NUMBER?
Now I am pulling a tooth.

I think OP may not be privy to the inside joke on the relationship between "half-century" and "@Peter's popcorn."

 

[mobil1syn]

WHAT NUMBER?
Now I am pulling a tooth.
I hope you realize that this could have been done days ago of drbitboy DMD, didn't need to pull teeth one post at a time.

the gains number, which from my internet readings takes you to laportes differential equation land which well is way above my head.

 

[drbitboy]

The PID instructions should ideally be in a Program in a 500ms periodic Task ...

I just realized: if OP can look at the PID display in Online mode via RSLogix/Studio 5000, then they could eyeball how frequently the values are changing (e.g. Output 75.12345 (%)). If it is well over 2Hz, then the PID is not running in a 500ms periodic task.

 

[drbitboy]

the gains number, which from my internet readings takes you to laportes differential equation land which well is way above my head.

No! Don't go there (yet).

We don't need diffeq or Laplace transforms to understand what a PLC PID is actually doing.

Those things will help with subtleties of tuning, and to have a deeper understanding of what is going on, but for most linear processes with minimal deadtime they, although fascinating, are simply overkill.

Because the PLC is a discrete, not continuous, machine, all we need are

1. a solid understanding of the PLC scan cycle,
2. the equations here,
3. a sense of proportion ,
4. and grade-school arithmetic.

 

[drbitboy]

... and should have 8hrs of trending today. ...

I look forward to those trends!
_

 

[Saffa]

Post #58 shows that the PIDs are probably in a 100ms task, in the image the OP included.

 

[drbitboy]

Post #58 shows that the PIDs are probably in a 100ms task, in the image the OP included.

Yah I thought so too, but OP's Post #58 is at best unclear whether that image is either from the current project, which has PID update times of 0.5s, or from a separate project. Also, I would be very surprised, with the pre-@MaxK tuning parameters, if the PID could come anywhere near generating the trend seen in p_100.png if it was not running in continuous mode; the arithmetic just does not work out at 500ms or even 100ms. Maybe someday we'll get a tooth confirming or denying that inference; eyeballing the the PID display update frequency in online mode would be definitive, IMO.

It is not unusual for someone unaware of PID timing requirements to put a PID in the continuous task by mistake. It would be unusual for someone to be aware of the timing requirements but put the PID in a task with the wrong period.

That said, it could also be five PIDs in the 100ms task with round robin execution, although I suspect that is more often a holdover of older, slower PLCs (SLC, PLC-5), not something that need be done in a C'Logix PLC.

More teeth need pullin'.

 

[mobil1syn]

Post #58 shows that the PIDs are probably in a 100ms task, in the image the OP included.

POST #58 is from an old job for a gas compression system. NOT related to this problem. when drbitboy started talking about timing i went diggin to validate my fuzzy memory. the developer there had like 30yrs all over the world running compressors. dude had it down to a science with all kinds of cool 'automated' tricks to allow for maximum nap time (he liked working from home).

 

[mobil1syn]

I look forward to those trends!
_

so here they are

fq-100 is the flow out of p1
fq-500 is the flow out of p2
lt-100 is t1 level
lt-300 is t2 level
t-1000 is the decant tank

flow and tank level all over the place, but the unit didnt shut down. tomorrow i will probably reduced the P on the p300 to try to increase response time. there is the one blimp on the flow trend when i got a HH level on t300 because p300 was slow to response.

 

[mobil1syn]

Note that, if we assign 0.0 as the value both of K_i and of K_d, then the timing of PID updates, whether in a Periodic or Continuous Task, does not affect its behavior significantly. But don't do that, because then you would have to manually supply a bias, startups would be harder, etc.

That 6856us (6.856ms) maximum scan time is more or less consistent with my estimated mean scan time of 5.5ms, and might support my hypothesis that the PID is running in a continuous task

it appears to be a continuous task, which if i understand what you are saying means its not consistently running the calculation so it causes issues.

 

[Saffa]

POST #58 is from an old job for a gas compression system. NOT related to this problem. when drbitboy started talking about timing i went diggin to validate my fuzzy memory. the developer there had like 30yrs all over the world running compressors. dude had it down to a science with all kinds of cool 'automated' tricks to allow for maximum nap time (he liked working from home).

Ah my bad, i probably should have read the posts a bit more closely.

I think I'll sit back and leave you in the capable hands of the Dr.

 

[drbitboy]

it appears to be a continuous task,

Sometimes the reverse tooth fairy provides more teeth than what the OP provides.

I gotta say it again, if for no other reason than so that it can be used against me the next time I am wrong : I'm not always right, but it does usually work out that way.

TL;DR

Okay, I am saying above don't read this, but it only takes grade school arithmetic to understand this, and if you do take the time to grok it, you may not be at the level of @Peter Nachtwey, but you will be ahead of many PLC programmers, and even engineers, when it comes to PIDs.

which if i understand what you are saying means its not consistently running the calculation so it causes issues.

It's not the inconsistency of the actual update times that is the problem, because the tanks' capacitance takes care of that.

The problem is that the PID is using @MaxK's most excellent K_i values assuming the update time is 500ms, while the actual update time is nearly two orders of magnitude less than that.

Consider the questionably-named "velocity" form of the PID equation (source):

​

• That calculates the the CV output at each update, CV_n+1, via an offset, ΔCV, from the previous update's CV_n
  • CV_n+1 = CV_n + ΔCV, where
  • ΔCV = K_pΔE + K_iEΔt + K_d...
• K_d is zero, so the last term is zero, and we are left with
  • ΔCV = K_pΔE + K_iEΔt
• Δt is the [Loop Update Time] parameter from the PID settings' [Configuration] tab
  • In our case, the value is 0.5s = 500ms,
• E is the error, PV-SP,
• ΔE is the change in E from the previous update [n], to the current update [n+1].
  • ΔE will be cumulative across several PID updates, so the effect of the proportional term over time is independent of the actual update time.
• Which leaves the integral term
  • K_iEΔt

So normally, that integral term is added to the CV output at each PID update, which should happen by design every 500ms (Δt), so the CV change due to the integral term is [K_iEΔt] every 500ms. The K_i values provided by @MaxK are intended to be used in a PID that updates once every 500ms.

However, since our PID executes in a continuous task, the PID updates and the CV changes by [K_iEΔt] every 5ms, or 100 times more frequently than by design, so the CV changes of order 100 times more rapidly than intended.

The proper way to fix this is to refactor the PLC program to put the PIDs into 100ms periodic tasks.

Since that is not possible, there are two ways to fix this without otherwise changing the PLC code:

• Change the [Loop Update Time] parameter to 0.005s in the PID [Configuration] tab;
• Scale the K_i tuning parameters by 0.01, to counteract the Loop Update Time that is 100 times larger than the actual update time. This is silly, but it would work.

Since the system is running without trips now, you might want to do that in gradual steps e.g. change the [Loop Update Time] parameter to 0.475s, and see if the result is better, or at least not worse. Then try 0.450s, then 0.400s, etc.

The key thing to understand is that the [Loop Update Time] parameter in the PID [Configuration] tab has nothing to do with the actual update time of the PID instruction.

 

[drbitboy]

Also, once the suggested tuning and update parameter changes are made, the system will run much more smoothly over the next day or so, and OP should have all the political ammo they need to be allowed to refactor the PID program itself.

At a minimum, the PID instructions have been mistakenly placed in a continuous task, and should be moved to a 500ms periodic task.

 

[drbitboy]

Finally, shame on me for not suspecting that the PID was running in a continuous task a week ago, when the first trend was posted.

 

[simjon71]

The PID instruction available for ladder is the older version that uses the positional formula. The newer one with velocity formula is called PIDE and is only available in FBD.
You can also add a timer to fix the timing issue of the PID, picture from Publication 1756-RM003X-EN-P