Is it OK to repeatedly reset the set point on a PID controller?

[MostEE]

Hey everyone, I have a 1/16 DIN temperature controller with a single setpoint with remote communications. I have written a simple time based program for ramping and holding (soak). The program basically just resets the setpoint periodically in order to achieve the desired temperature based on a rate or time. There is no PID control algorithm with the program. The "system" relies on the PID in the controller to maintain the temperature. The device for which I am controlling the temperature is a somewhat fast response system; in the order of 10s of seconds to to change from 25C to 100C. Knowing that a PID controller is constantly calculating and setting the control output, my question is: Will resetting the setpoint every 10 seconds throw off the PID?

Thanks in advance!

 

[analogkid2digitalman]

May depend on how the loop is tuned and how large the change in setpoints are versus how the system responds.

Why not give it a try and monitor actual temperature?

There are numerous PID based ramp/soak controllers available on the market.

-AK2DM

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"It's the questions that drive us"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[IRstuff]

Are you worried about hurting its feelings? ;-)

A commercial PID controller ought to be able to handle ANY setpoint withing its specified allowable range. The only concern one might have is a technical one: if the response time is on the order of "10s of seconds" and you change the setpoint every 10 seconds, then you may not have the temperature ramp that you think you should be getting. That is, you might wind up with a bunch of smaller responses with one giant step at the end.

You should do some testing to make sure.

TTFN

FAQ731-376
Chinese prisoner wins Nobel Peace Prize

 

[danw2]

Most controllers write to setpoint to some form of non-volatile memory (in case power fails) and the non-volatile memory might have a finite number of re-writes. I discovered this in the mid-'90's when a controller failed after about 6 months. It was taking one second updates 24-7.

Finding out whether this is the case or not with a particular model is very problematic, because the one guy who might know lives half way around the world and your contact is a sales office in the other half of the world. That manufacturer has no clue whether today's equivalent model has the same limitation.

 

[lacajun]

In the Dark Ages, changing setpoints also meant retuning the PID to maintain good control.

Pamela K. Quillin, P.E.
Quillin Engineering, LLC

 

[MostEE]

Thanks everyone. Some comments to your replies:

analogkid2digitalman: I am aware that there are numerous PID based ramp/soak controllers available. The goal is to have everything monitored and programmed from a common front end using LabVIEW. This will also allow us to subsitute the PID controllers in the future without having to retrain the research people.

IRstuff: Very good point. I have done some testing "on the bench" but nothing is as good as testing in the actual system. Thanks for the vote of confidence on modern PID controller being able to handle a setpoint change within its range. This directly addressed my concern.

danw2: Great point too. My particular controller has both a volatile and non-volatile write instruction. I am writing to the volatiel one for that reason. As an added note - writing to the non-volatile causes and annoying reset of the display/controller which wasn't desirable anyways.

lacajun: Yes, retuning the PID was exactly my concern.

Thanks again!

 

[danw2]

Sometimes there's a functions like output rate limitation or choice of PID implementation that can effect the outcome, for example,

PID B — Unlike the PID A equation, the controller gives only an integral response to a setpoint change, with no effect on the output due to the gain or rate action, and it gives full response to PV changes. Otherwise controller action is as described for the PID A equation.

>This will also allow us to subsitute the PID controllers in the future.

I assume you are writing values via some digital protocol, ASCII or Modbus (as opposed to generating a voltage signal to a 2nd input on the controller). You should be aware that there's absolutely no standard for mapping digital comm values or the format used.

Your current model might take signed integer, the next one floating point, or signed integer*20, whatever. Not that those issues can't be addressed, but changing brands is never plug and play when it comes to digital comm.

So whatever you pick and stick with should have a suitable lifespan because changing brands will require changing the program you use to write the values.

 

[MostEE]

danw2: Thanks for the note on the different PID types. Good point. I can look into it but think that this will get flushed out in my testing. As for the to swapping controllers, I will need to write a lower level "driver" in the LabVIEW code for each new controller. The end result is that the end user will still only need to know the LabVIEW interface. The main reason for all this is that we are still in a "research"/development phase. When we transistion to a more standard product, we will settly on one controller.

 

[FeX32]

If the original system is non-linear in nature (as most real systems are), and there is a very large change in set point, there is a possibility that the system will become unstable. This is theoretically provable. If the corresponding gains are not too harsh (not for very quick response) you should be fine. You may want to conduct a simple simulation first.




Fe

 

[MostEE]

danw2: Sory, but I replied earlier and it did not seamt to post. Thanks for the tip on the various PID methods. As for changing brands - the LabVIEW will certainly need to have a lower level custom "driver" for any new controller that is introduced. The goal behind this design is that my end user will not need to learn how to program a new controller. They will continue to use LabVIEW screens they are familiar with.

Thanks!

 

[FeX32]

Beware. Proper analysis is important...
Neglect in engineering is the reason for many faults and accidents. Have fun with your elementary PID controller.


Fe

 

[MostEE]

FeX32: Elementary? What is your recommended approach when the criteria is one "user interface", in this case LabVIEW?

 

[FeX32]

I am merely referring to your disregard for a proper control engineering analysis. Your system is likely nonlinear and while a PID controller is likely to function most of the time it certainly will fail in predefined situations/occurrences or cause bad control. Once you have done your analysis and maybe a simulation you can judge wether a more advanced controller is needed to ensure proper operation. There are many such as 1 of hundreds of Lyapunov based nonlinear controllers, sliding mode controllers, adaptive controllers ect.
If in the user interface only the setpoint is changed then any controller can be programmed into place.
I know a lot of the times what ends up happening is that the designer just tests physically it to ensure operation. This is alright I guess, but not really ideal and not engineering. That's all.
Have a good one.


Fe

 

[MostEE]

FeX32: It is certainly not my intention to disregard proper control engineering analysis. That is in fact why I posted the question - to solicit advice and guidance. In the spirit of this forum, perhaps you could point me to some literature or tutorials on "proper control engineering analysis" for my situation.

Thanks.

 

[FeX32]

Start with Control Engineering by Ogata. I believe there may even be examples with temperature control. Although, they likely linearised the plant. Maybe you can do the same for yours (given certain conditions), and then you would validate the use of a PID cotroller.
Try to figure out (derive) the dynamic model for your temperature control system. And work from there.
Good luck


Fe

 

[MostEE]

I thought I would share some information I received from one of the PID temperature controller manufacturers:

Any given PID set is good for @ +/- 200? from its tuning point. Only if you exceed this should you consider using another PID set. Some controllers have a feature called Gain Scheduling. You’d tune it at several setpoints and set a boundary at which it would change PID sets.

You could use another feature of some controllers called 'adaptive tune' which recalculates the PID settings on the fly when the deviation is at a set threshold, but this is disruptive to many processes.

Thanks again for all your input.