PID headache!

Could somebody please help point me in the right direction with a small problem i've got with a basic PID control process i'm trying to commission?

I'm using a Siemens S7315-2DP processor (using the FB_41 CONT_C block) and am attempting to control the temperature of an air supply feeding into a Nitrogen generation plant. All i need to do is maintain 100 deg F (all units are imperial as per customer request) for the air temperature.

The actual temperature controlling is working absolutely fine (it deviates about 0.5 deg F, but thats more than acceptable), the problem i have is on initial start up. When the systenm is first powered up from cold, the temperature over shoots by about 20 deg F, then after approx 10 mins or so it settles down nicely to the 100 deg F sepoint temperature. I've never really had anything to do with PID and am unsure of which parameter to adjust (I've tinkered with Ti a little - but not very successfully).

This isn't a critical application, but is just annoying, as it flags up a HIGH TEMP alarm on initial start up.


Any help would be appreciated.

You are experiencing what it known as "reset windup". This is a common phenomenon, and means that the effect of the integral term accumulates while the process is getting started, causing a built up overshoot in the contrlled variable like valve position.

I don't know about Siemens, but many PID algorithms have built in "anti-reset windup" functions. Do a little manual reading, and if you can't find it in Siemens come back here and we can give a little help in "roll your own".

You need more differentiator.

I am assuming the temperature is making a step change from ambient to 100 degrees F. This will cause the interator to wind up while there is an error. This can be offset my using more differentiator or reducing the integrator. A simplistic way of getting around the problem is to keep the integrator off until the temperature gets close the the set point.

Try adjusting the Td a little higher. Your P and I are probably close enough since your running control is acceptable.

You are controlling an air stream which is an extremely fast variable, that is probably heated by a resistance heater that has some delays. Set your output cycle time to a fast number and set your sensor to a fast read mode (or reduce any time delayed sensor averaging).

Greetings Rob,

in addition to the excellent advice already offered, here is a “quick and dirty” method that might be of interest ... keep in mind that I personally have ZERO experience with Siemens so I have no idea how hard this would be to set up on your system ... but in an Allen-Bradley, this would take only a few rungs of programming to implement ...

[attachment]

one big advantage to this method is that there is no need to alter your existing PID tuning (assuming that it handles the process adequately once things have settled down near the target) ...

note that the shift into “warm up” mode at startup – and the shift into “PID mode” once the process is close enough to the setpoint - could all be programmed to happen automatically ... specifically, the operator shouldn’t have to make the selection from one mode to the other ...

one thing to watch out for: if operating conditions change dramatically (for example: unexpectedly cold inlet air temperature) then the manual mode setting might not be enough to get the process “close enough” to the target for the system to shift into PID mode ... you might want to add a “just in case” timer to the program to handle the shift for cases like this ...

finally ... if none of the help being offered proves to be adequate, then consider posting a trend graph of your system’s response ... I’m sure that someone will be able to help you through this once we can see more of what’s going on ...

I've quite often used a set point ramp to avoid start-up problems. Start the set point at ambient say, then ramp it at a rate the process can track to the final value.

Yes, all of these methods work, under certain circumstances. Additional methods that I've used: dual temperature setpoints (maybe 90, wait x min to stabilize, then 100), dual PID (conservative PIDs on start up and tighter PIDs on running), etc.

Since your only concern is the alarm flag, you also could inhibit the flag for 10 minutes at start up and never mess with these other items.

None of these tricks are required if the system is properly tuned. A properly tuned system will have a near critically damped response and therefore little if any overshoot.

Peter Nachtwey said:

None of these tricks are required if the system is properly tuned. A properly tuned system will have a near critically damped response and therefore little if any overshoot.

Click to expand...

I welcome any corrections but I think that's simply not possible in the real world in many systems. Due to:

- lag due to signal travel time.

- Many startup involve conditon not encountered during steady state operation such as additonal feed, fluids, entrained components.

- Chemical/thermal action unique to the steady-state or startup operation.

Of course, that beg the question of what is defined as a system. I am just saying that during startup the system dynamic can be fundamentally different. Hence, a different PID parameter is required or use one of the "tricks".

if the system is properly tuned

Click to expand...

And there in lies the problem......I am more than willing to admit that at the moment PID is not something i am totally familiar or comfortable with (i understand the basic principle of operation), just not some of the more involved settings.

For this particular application, i'm more happy with Ron Beaufort's suggestion of the initial MANUAL mode approach (this i can understand!). Not that the other solutions/suggestions were ignored, just that i find some of the concepts a little daunting at the moment!

Thank you all for your input, and i fully intend to re-read the above suggestions and attempt to implement some of them at a later date on another application (where i have a little more time to experiment for myself)

Thank you again.

A properly tuned system will have a near critically damped response and therefore little if any overshoot.

Click to expand...

Critical damping is only one example of "proper tuning". There are many figures of merit for tuning, e.g. integral of absolute error. It may be better to get faster response at the expense of some overshoot. The classical Ziegler-Nichols tuning is for "quarter wave" response, which would look very oscillatory today. I blame the trend object we all program on our HMIs for making this look bad.

Given that most systems are non-linear to a greater or lesser degree, for the simple stuff I do, I find it easier to do the system identification close to the operating point, then use "tricks" to get there on start-up. I also like Ron's method above, though I usually use the "last known good" CV in manual.

Switching from auto to manual has lots of advantages, but be careful. I witnessed one machine where, during a production change over, the 70 temp zones were switched to manual, and then set to idle at 100.

The operator was overworked and involved in numerous other tasks. He did not immediately comprehend what he did, and left that part of the building.

It was an expensive education.

(Yes, I know that there are 1000 reasons why this should not have happened. But it did, with medium-experienced people, on a very expensive machine.)

FB41 vs. FB58

If you have Step 7 version 5.2 and newer there is an additional PID, called FB58 TCONT_C. Have you tried that block instead of FB41 ?