# Smarter temperature controller?

#### runescape

I have a machine that has a PLC temperature controller that tries to maintain a constant high temperature. The controller can only heat (not cool). Heat is being lost at a faster rate when the machine is running, compared to when stopped. So the first minute or so of startup will have a temperature undershoot, and there will be overshoot after the machine stops. The machine currently uses the same PID parameters all the time.

Note that the amount of undershoot/overshoot happens to be inconsequential for my application, but I was wondering if it can be improved.

I am thinking of either:
1. creating 3 different sets of PID parameters: an aggressive one for the first minute of startup, a mellow one for the first minute of stop, and the goldilocks one for everything else.
or
2. intentionally changing the target temperature on startup and stop. So +10 on startup, -10 on stop, with perhaps ramping back to the correct target temperature.

I forget the nitty gritty of PID loop theory. But my general thought is that the loop is reactionary to temperature errors, and is looking at the past to decide on the present, therefore is slow/weak against a dramatic change such as startup/stop.

Hence why I am considering option 2, which takes advantage of the knowledge that the machine is starting/stopping. The changing of target temperatures should have the effect of immediately tricking the loop into reacting faster. A lower target temperature (at the moment of stop) will basically trick the output heat to turn off. A higher target temperature (at the moment of startup) tricks the output heat to immediately turn on.

Does anyone have suggestions on which choice is better?

I particularly want opinions from the lens of the mathematical nitty gritty theory. For example, it could be that option 2 is mathematically a Rube Goldberg version of option 1? Or is there an easier way to do this?

Thanks, and happy new year!

#### pnachtwey

What you are suggesting are kludges..

Your are too focused on the PID and not the process! How high? What is happening when the machine is running? If the machine is heating up widgets then it will obviously take more heat if the flow of widget through you machine/furnace is faster. When the machine stops, the output is too high unless you reduce the heat as a function of flow or running speed.

#### runescape

The machine is maintaining about 240 C temperature on a big mass of metal, via heating elements. The machine runs 24/7 with only brief hourly maintenance, so the metal is kept always at 240 C.

When running, the metal touches the widgets, transferring a tiny amount of conductive heat to the widgets, at about 250 transfers per minute. When stopped, the metal has minimal conductive loss.

There is lag between outputting to the elements and the metal getting hotter. So the PID is needed to keep the temperatures even, which it does quite well. The only problem is the startup and stop events, where it would be nice if the PID would respond sooner.

On startup, ideally the heating elements would crank up in anticipation of the higher heat losses about to come. But the nature of PID I think means that it will take several loops for the integral and derivitive to finally stabilize to the new situation.

Same for stopping. Ideally, the heating elements will cut off, because there are no longer any widgets pulling energy away. But PID will still be producing heat as if the machine were running, until several loops later.

My thoughts are to trick the PID loop, by highballing the target temperature to 250 on startup, which effectively cranks the heat up. Then maybe I'll drop it or ramp it down to 240 after the PID math has gotten used to the new running situation? Same with stopping: I'll drop it to 230, so the PID will immediately shut off the elements. Then I'll wait a few seconds before setting the target to 240?

Seems kind of Rube Goldberg, but how else would I be able to apply awareness of startup/stop to a PID loop?

Like I said in OP, for my application/widgets have no particular consequence to small temperature fluctuations.

So I am mostly just playing around with theory. Who knows, maybe some other applications out in the world do need a faster response.

In my experience, I have only ever heard of some standalone temperature controllers having multiple "PID profiles", where you can select which PID recipe to use. But I have never heard of something that does anything that highballs/lowballs the target in order to get a jumpstart on response. It seems like there is no way to apply awareness of a sudden change to PID math.

#### patrickduis

We solved these kind of "problems" many times.

We help many companies improve their temperature controls. PLCs are not that great in controlling temperature as a -real- separate PID controller does. We already improved many processes, by replacing the PLC PID control with our Japanese RKC controllers. The PLC works as before but only the PID control is taking over by the RKC system.
We then connect it over the often already present fieldbus (ProfiNET, EtherCAT, DeviceNET, EtherNet/IP, Modbus RTU RS-485/TCP ethernet or similar) and improve the accuracy and responsiveness of the process enormously. This often leads to an improved quality of the output, often combined with increased production capacity.

Our RKC controllers have specific settings when a process starts to prevent overshoot. Only after reaching the setpoint it starts the "normal" way of controlling. Also when changing setpoints (also danger of overshoot) it acts that way.

We also have controllers that have so-called "external disturbance suppression" or EDS for short. A digital input (or command over the fieldbus) tells the controller that for example a door is open, or now no product comes into the oven. We "train" the PID controller separately in this situation so it automatically uses other parameters in this case. And when the input signal (or command) goes off, it starts using the normal situation tuned PID parameters.

Our RKC Instrument controllers also have sets of 8 or 16 (depening on model) parameters and you can switch those sets of parameters (this includes PID settings, but many more) with communication commands, or with digital input signals.

So there are lots of possiblities for you to chooese from. See here an extensive overview of our accurate and reliable (MBTF times>40 year) Japanese RKC Instrument controllers: https://cascade.net/en/controllers/

And contact me if you want me to help you improve your temperature control. We're there for you to help.

#### ArthurM

Changing tuning parameters (adaptive tuning) can be done for varying process conditions, but since this is a start/stop condition it may be easiest to simply bump the output during start/stop. You historically look at where the output needs to be and flag that pre-position during start/stop events. Adaptive tuning would be more involved. If using derivative, programmed setpoint changes may be problematic.

#### GMcc

Put the PID controller in manual and see if you can make the system heat up faster at start up or cool down faster at shutdown than when it is in automatic.
Your system will always have a lag at start up/shutdown if you have electric heating elements, also need to look at where and how you are measuring the temperature.
If you can make the system respond quicker in manual then tuning PID parameters, alternative sets of PID parameters or preloading output before putting PID controller in automatic may improve things.
It is normal for a PID controller to have some overshoot/undershoot during change of conditions. If you could record and post a trend of the set point, process value and output from the PID controller we can tell you how well the system is tuned.
Having a PID controller in the PLC is the modern solution and easier to integrate with other processes. Nowadays I only see standalone PID controllers used in simple machines where a PLC is not needed.

#### BobM

You could modify the High and Low Output limits on Startup and Shutdown. You also have to Figure in Safety though. Timers on the High, Low Limits. If you lose Scan or Communications you better make sure you have Failsafe Open Parameters and/or Valve for Cooling..Good Luck