Quick comparison of PID, PIDE, and PI instructions in RSLogix5000 ...

[AH_GB]

How to adapt to speed of response changes

I have periodically come across a problem which must be common enough for someone to have put some thought into. We have an off-gas system, which takes waste gases and processes them to remove contaminants.

As the quantity of material going in upstream varies, the speed of gas flow changes, and consequently the response of the PV to the CV changes. In essence there is a variable time delay in the feedback loop. With a fast gas speed we can use higher integral gains with good control and still get a stable loop, but under slower conditions the parameters can be unstable, so we are forced to use cautious lower gains.

We can get an idea of what this time delay might be (from the quantities of material added), but it isn't so straight-forward to use that information. I have tried an element of feed-forward, with varying success, and have toyed with the idea of using dependent gains (which means the integral gain and derivative gain are essentially times), and adjusting these times to match the speed, but am concerned in case the system becomes unstable when I'm not watching it.

Has anyone got any relevant pointers or experience?

 

[JLand]

Maybe instead of tuning parameters as a continuous function of flow rate you could set up a few different flow conditions (e.g. low, medium, and high) and tune the loop independently within the flow conditions. You could move these tuning parameters into the PID instruction based on the flow conditions (with some hysteresis built in, of course).

This way you're much less likely the system becomes unstable when you are away and each set of tuning parameters has a much smaller window of process conditions to account for.

Just a thought. I am sure there's a better way to do it.

 

[drbitboy]

As noted earlier in this thread, you will want the velocity form of the PID, and the derivative action based on PV instead of ERror.

 

[Peter Nachtwey]

You have correctly surmised that the effective gain for the I and D should be higher as the flow increases.

AH_GB, are you familiar with the chain rule? Basically you don't want to run you PID or time constants as a function of time but as a function of flow.

 

[AH_GB]

Hello Peter. I'm not familiar - can you enlighten me?

 

[Peter Nachtwey]

The chain rule is a calculus thing.

Hello Peter. I'm not familiar - can you enlighten me?

The chain rule according to the "instructors"
https://www.khanacademy.org/math/ap-calculus-ab/ab-differentiation-2-new/ab-3-1a/a/chain-rule-review


However, I will try to simplify using a practical example.
lets say you want to make a line following robot like this
https://www.youtube.com/watch?v=IVGUzuMG-J0
This example is extremely good and probably uses the chain rule.


For starters, assume you have only proportional controller that detected only how far the car is from the line. It is clear that the wheel would angle or try to reduce the error depending on the distance the cart is from the line. This is easy. However, this method may not work if the car speed is very fast.


What would happen if we added an integrator?
What if the car was slow or stopped? It is easy to see if he integrator is based on time. like in most applications, the integrator would wind up if the car was stopped and there was a little bit of error. The problem is that the in the "stupid" case the integrator winds up based on time even when the car is stopped. It is clear the integrator would wind up even though the car is stopped. The integrator should wind up or down as a function of distance.




Think about this. I don't want to spell it all out because it would ruin some of the joy of figuring it out.


If normal integral term for normal systems is

CV(n) = CV(n-1)*Ki*Δt*Error

What must be added to take into account the speed of the system?


If anyone knows besides AH_GB, then pm me. Let AH_GB figure this out himself.

 

[Peter Nachtwey]

It is clear this type of problem escapes people. AH_GB's problem is that the PID shouldn't be based on time alone but also the flow rate.
In the case of the line following car, one doesn't want the integrator to windup while stopped but a little off the line. The equation I wrote above needs to be modified like this

CV(n) = CV(n-1)*Ki*(Δx/Δt)*Δt*Error

Where:
Δx is the distance covered in the sample time Δt
This can be simplified to

CV(n) = CV(n-1)*Ki*velocity*Δt*Error
or
CV(n) = CV(n-1)*Ki*Δx*Error

Since the PID is updating every Δt it is best to use the form that has the Δt in it.


So in AH_GB's case the flow is analogous to the velocity so he would use

CV(n) = CV(n-1)*Ki*flow*Δt*Error

Which is exactly what AH_GB said. The effective integrator gain needs to be higher when the flow is higher. I just proved what AH_GB is seeing.

 

[AH_GB]

Hello Peter

Thanks for the clarification and the example; I had remembered the chain rule as "function of a function" which is what we called it as school, so solving these brings back fond memories.

Needless to say, the real world is a bit more messy, with the transfer function being influenced by heat loss and chemical reactions in the pipes, etc, which tend to make it a bit befuddled, which is why simplistic solutions like the PID tend to reign.

To be obstinate I will roll my own VPID and see what happens. I guess that the solution is bounded by a time lapse - so fundamentally, if there is a time lapse in the transfer function then you cannot react to changes that occur in the time between the output changing and the process variable reacting to the change.

 

[Peter Nachtwey]

To be obstinate I will roll my own VPID and see what happens.

Your application requires a custom PID based on rates too.

I guess that the solution is bounded by a time lapse - so fundamentally, if there is a time lapse in the transfer function then you cannot react to changes that occur in the time between the output changing and the process variable reacting to the change.

What is a time lapse? Hopefully you don't mean dead time.

 

[drbitboy]

A PID is normally run on a regular schedule, i.e. fixed update time, because the I and D scaling parameter values chosen typically assume a process that behaves a certain way temporally.

A fixed update time can be best implemented by putting the PID in a task executed by a timed interrupt that executes every [update time] milliseconds. Depending on the process dynamics and the PID implementation, it might be adequate to run the PID in a continuous task but only triggered by the .DN/.Q/done bit of a repeating TON timer. Again, that depends of process dynamics; largish batches of material or tanks with heat loss and chemical reactions would, I suspect, often fall into this category, so any variation in the actual update time would disappear in the noise, and in actual operation this approach would be good enough.

The TON timer in such a case accumulates time since the last update, which eventually exceeds the update time on one scan, which triggers the .DN/.Q/done bit and executes the PID on that scan, and resets (restarts) the timer.

Say we replace the TON timer measuring and accumulating time with some logic that measures flow and accumulates the quantity of material passing in or out of the process since the last scan when the PID executes, and triggers the PID after some fixed amount of accumulate material. That would effectively scale the I and D action without changing the I and D constants; the P action would be relatively unaffected, although it would be updated more or less often.

I have not thought it through, but at first blush I think it would change the I dynamics in the right direction, and the D dynamics in the wrong direction. Also, at very low rates, it would all but turn the PID off, so there might be a need to execute the PID at least once every N seconds.

That said, it is one way to have flow-dependent parameters with an existing PID.

Update:

Another way to accomplish more or less the same thing would be to calculate the PID error (MeasuredValue - TargetValue, or vice versa) external to the PID, scale it with some function of measured flow, and use that scaled error as the PV to the PID instruction, and assign a PID setpoint of 0, and continue using time as the update/execute criterion. If the existing tuning is based on, or know to be adequat at, some known process flow rate, the error scaling step could use the ratio of the measured flow rate with that known flow rate, and the tuning constants might not need to change.

 

[Peter Nachtwey]

I have not thought it through, but at first blush I think it would change the I dynamics in the right direction, and the D dynamics in the wrong direction. Also, at very low rates, it would all but turn the PID off, so there might be a need to execute the PID at least once every N seconds.

The derivative gain gets scaled as a function of speed or flow too. It will work. Most of the time we think of time constants but in the AH_GB's case we need to think in terms of a flow constant but the PID still should be calculated at a consistent rate.

If the PIDE allows changing gains on-the-fly then one could still use the PIDE and scale the integrator and derivative gains each update.

Update:

Another way to accomplish more or less the same thing would be to calculate the PID error (MeasuredValue - TargetValue, or vice versa) external to the PID, scale it with some function of measured flow, and use that scaled error as the PV to the PID instruction, and assign a PID setpoint of 0, and continue using time as the update/execute criterion. If the existing tuning is based on, or know to be adequat at, some known process flow rate, the error scaling step could use the ratio of the measured flow rate with that known flow rate, and the tuning constants might not need to change.

NO! scaling the error affects the proportional gain.

 

[drbitboy]

NO! scaling the error affects the proportional gain.

d'Oh! Of course, thanks for the sanity check, @Peter.

 

[AH_GB]

Thanks for the replies guys. Yes, I have considered scaling the executions by volume flow rather than by time, but wondered whether this is something that might be catered for by some obscure parameter of a PIDE, as otherwise we are rolling our own block (not that that is such an unspeakable activity)

We inevitably hit problems when at very low flow, hence the "time lapse" or "dead time" - whichever way you refer to it, the actions of a PID are always retrospective, but in this case they are more pronouncedly retrospective.

For example, when you consider that the gas in the pipe is going to be cooling down in transit, the normal PID values - even adjusting for flow - probably won't work, so in this case turning the PID off (forced manual bypass) might do the trick.

The approach I am contemplating is to put the output and setpoint data into a buffer (volume series, not time series), to allow these to correlate with the input data, then maybe feeding these values (together with the flow rate) to a neural net. However, all this could end up being over-complex, and missing the point of the PID (keep it stupid, simple) - and implementing a neural network on a PLC might be a new one, too.

Again, suggestions welcome.