Cascade control to regulate the fluid temperature in heating tank

Hi everyone,

I have a question regarding the implementation of a cascade control for temperature regulation and I hope I can get some help for the problem that I am facing. I got an extra project at my university to develop a new tuning procedure for multivariable PID systems using optimization techniques, and as a validation step, I am attempting to apply it to a heating tank process connected to a Delta V system. However, I am facing a modelling issue that I believe is related to the delta V implementation.

The tank has two inlet streams supplying cold and hot water, which I am attempting to control the level with the cold stream and the temperature with the hot stream. Because I faced problems with valve stiction plus low frequency disturbances in the flow rates coming from building supply, I decided to use cascade control in each loop in a way that the inner loop controls the flow. All sensors are not HART and FIELD_VAL_PCT is used. The thermocouple is Type J from Omega Engineering and the level is measured using a Differential Pressure transmitter.

After running few experiments in the unit, I built a  SIMULINK model and simulated the controlled process considering two PI master controllers, which matched the closed-loop response of level quite well but failed to describe the temperature. The hot water flow rate had a initial kick due to the proportional action but then it started to slowly increase as almost a straight line pattern. After reading a similar thread in this website, I thought the mismatch was caused by the implementation differences in the PID algorithm used in MATLAB and Delta V to handle reset windup. But all BKCAL_IN and BKCAL_OUT signals were tagged as "GoodCascade" during the experiment and I believe the integral action was not being turned off (Please correct me if I am wrong). AIso, I set the OUT limits the same as ARW ones for both inner and outer loops; however, none of them were crossed.

When I further analyzed the temperature data retrieved from the delta V, I realized that as soon as I put the temperature master loop in auto mode the noise in signal disappeared and a given value of temperature was held for intervals ranging from 5 sec to 8 sec. Also, plotting the data showed a trend that looked like small steps while in open-loop the noise was very clear. 

My question: Could this problem be related to the thermocouple resolution, scan rate, or ARW? I've been investigating this for weeks and I could not find a good advice anywhere. I would really appreciate your help on this issue.

Best Regards,

Eugenio

  • Eugenio,
    Wow! This is a strange one! It sounds like you have done a lot things correctly! All the items you mention could cause some of this affect but I cannot think of anything about the PID that would change the appearance of the trended PID1/PV depending on whether the PID is in Auto or Manual. What are the execution periods of the master and slave loop modules? Can you send pictures of the modules in the on-line mode. If possible, send me the configuration export ("fhx") file and I will take a look at it.
    James
  • Hi there,

    First thing why did you couple the loops as proposed? Temperature control is a blending problem so I would have a ratio controller between the hot and cold water, which is set by the temperature loop, or ratio the hot to the cold stream flow, set by the temperature. Maybe that is what you have done ?

    Then the windup you talk of should not happen provided you disable the ARW feature on the PID block. From FRSIPID_OPTS, uncheck the ARW option. That would rule out the possibility of ARW dragging the master loop.

    The noise/PV you are talking of. That one is strange I have never seen that. The only time i have seen issues like that is if the resolution of the historian is set too large, in which case the sampling will look like steps. If you are scanning with OPC then I have no idea to be honest. I will dig around with a test system and see if I can work it out. Also just an FYI - you can simulate the entire problem in DeltaV using the H&M balances for water. What version of DeltaV are you using ?

    Regards
    Paul Hughes
  • In reply to James Beall:

    James

    Thanks so much for your reply and I really appreciate your help. Regarding the noise issue, I actually looked to the wrong the section of the data by mistake and I confused the region where I turned on the mixer with where I put in auto. The random variation was smoothed out after I started the mixing and not when I put the controller in auto. Sorry about that.

    James: Please find attached the requested files, I am also sending a excel files with a portion of data that I collected other. It shows the constant value of T for a long interval. I built the cascade structure within the same module. A scan rate of 1 sec is applied to both modules and blocks within it. There are few things that I should point out:

    1) I had major issues tuning the inner PID for the temperature loop and it is not near optimal due to major hardware issue with this experimental unit. The valve is oversized and has a stiction issue. Also, as I mentioned before, the hot water supply is connected to the whole building and major disturbances were affecting the system in a way that under complete manual mode the flow rate changed severely for a constant valve %. Therefore, I could not identify a model to use the lambda-tuning or other techniques. So I had to do the tuning using trial-and-error, which was a lot of work.

    2) To minimize the stiction problem, I used the derivative action with filter to allow some noise to affect the system and cause the valve to constantly move in high frequency and avoid it to get stuck. The tank has good inertia and these oscillations are smoothed out before affecting the temperature (Correct me if I am wrong). The tuning for inner PID for the level module worked quite well but the temperature is much more affected by those hardware and external disturbance issues and the performance is not very good, even though it is the best that I could get after the experiments. I tried other features in Delta V such as Deadband, Nonlinear Gain, etc. but nothing changed much plus I would not be able to reproduce those features in MATLAB.

    Regards,

    Eugenio

    The fhx files can be downloaded from the link: https://drive.google.com/open?id=1krjYUENlHYRbb2X-KL-558d4KBIvvjE-

  • In reply to Paul Hughes:

    Hi Paul,

    Thanks so much for your reply and I really appreciate your help. The main reason is because the target of the research is to develop a tuning methodology using optimization for Multivariable interacting PID loops. As the level is already being controlled by cold water and it also affects the temperature, the method would minimize a objective function that would balance the effect of interactions and overshoot while keeping both loops fast for SP tracking and regulation purposes.

    About the FRSIPID_OPTS, do you mean enabling the Dynamic Reset Limit option? I can't finding a specific ARW option to be selected.

    The noise/PV was a mistake because I said in my previous reply, I looked at different regions in the data when I said that. Actually the noise smooth out after I turned on the mixing and not after switching control modes. Unfortunately, we do not have a license for the OPC feature and we need matlab because the entire tuning problem is solved with MATLAB Optimization Toolbox.

    Regarding, the resolution of the historian, could you please teach me how to check that?

    Best Regards,
    Eugenio
  • I found the problem after talking with someone from Emerson in Canada, I got confused with the definition of proportional gain in the algorithm used in Delta V. The Kc that should be set in the PID block is a normalized value

    Kc (Delta V) = Kc (EU units) * (Range of PV)/(Range of Controller Output)

    However, I was putting the Kc that I calculated in Engineering Units directly in the bock. After making the modification in the MATLAB code I could match the data.

    Thanks everyone
    Eugenio

  • In reply to Eugenio Turco neto:

    Eugenio,
    That is great! I am glad that you discovered this fact. Note that this and all DeltaV information is available in the on-line documentation in DeltaV (Books On Line).

    I was able to import you configuration and observed the tuning on the flow loops. The cold water flow loop (cascade with LIC) has Gain=2, Reset=70 seconds, Rate=4 seconds. The hot water flow loop (cascade with LIC) has Gain=2, Reset=60 seconds, Rate=3.5 seconds. I know that you note that the valves have significant non-linearities and that you added derivative (Rate). I hesitate to provide tuning with out process response data but a more typical flow controller tuning would be Gain=0.2, Reset = 3 sec and Rate=0 sec. (This is ~ Gain = 1/3*(1/Kp%/%), Reset = process time constant). Make sure any filtering on the flow PV signal is less than 1 second.

    Let me know the results!

    James
  • In reply to Eugenio Turco neto:

    The problem with university studies, I have seen, is that they show the Laplace domain mathematics but gloss over how this is converted to the time or discrete domain. As a result of this I ended up making videos explaining this : www.youtube.com/watch
    The Yok help documents are far more explicit in terms of the implementation detail, whereas the BOL from Emerson still show the Laplace formulae. To be honest, I have never tuned a level with derivative action. Typical settings would be gain from 2 upwards, and reset from 5 to 20 minutes. Temeperature control in the real world would be more complex since the tanks are not normally well mixed, and they often exhibit process deadtime. Also another few gems which very few people keep in mind : a good rule of thumb for a control valve stroke time is 1"/s. So this means for a 10" valve, it does not make sense to have a reset less than 10s. Since flow measurement is noisy, i would have to disagree with the filtering recommendation. In many cases I often filter the flow measurement more than 1second, in steam flows I have done even 10-20 seconds.

    Have fun!
    Paul Hughes
  • In reply to Paul Hughes:

    I'm in a agreement with Paul and James. A self regulating loop with smaller gain and shorter seconds to repeat. Integrating loops like level have an integrator built into the process and reset action in the PID creates two integrators in series which inevitably result in oscillation. Integrating loops benefit from primarily proportional action. And even more so for feed forward.

    When it come to derivative action, most explanations I've heard start with "D is for don't use." I learned that the purpose of the derivative term is to address the secondary lag in the process. Temperature loops often display this in heat exchangers and is easier to implement in this process. But control valve air/spring actuators are a source of secondary lag and the larger the valve the bigger the lag.

    Rather than increase the gain on such self regulating loops, a bit of derivative can be added to address the valve lag and keep the reset as the drive the valve smoothly to achieve setpoint. The point is to look at the secondary lag, which shows up as a slow start to the process response.

    As James pointed out, one should evaluate the process response before suggesting tuning. Also the desired closed loop response needs to be defined. In a hearing/mixing application a fast response is likely desired as any overshoot in fast response is absorbed in the retention time of the tank.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Andre,
    I read with interest you response referencing the PID loop. I have been working with PID loops for years, but when it comes to explaining the basics to a new technician I am lacking in the basics. Do you know of a basic guide for PID loops for a new person? The basics being what each component in the PID i.e. Rate, Reset, Gain performs in the process. We mainly use PID for Back Pressure, Temperature, and Level controls.
    Steve
  • In reply to SteveWJ:

    HI Steve- I think the link I added above should do what is needed. I have created a few Youtube videos to try and explain the basics. Let me know if this does not achieve what is needed, and I will augment as needed :)
    Paul
    www.youtube.com/watch
  • In reply to SteveWJ:

    Sorry Steve. Most of my insights came from a course with Michel Ruel in Quebec and his text book wa sin French, about 25 yrs ago....

    I had a listen to Paul's YouTube link and it was informative. I have not listened to its entirety so I don't know if it will get you what you need, but it is certainly worth a look.

    Paul points out the most DCS apply a filter in the derivative term to minimize response to noise and get more stability. To be useful there must be a secondary lag that passes this filter. This lag is different from noise as it is present on valve movement.

    My guidelines are:
    Proportional action: primary factor in integrating loops, little or no reset.
    Integral action: primary factor in self regulating loops. I.e. repeat a small gain quickly to reach steady state. Increase gain for faster response and some overshoot.
    Derivative: addresses secondary lag if present.

    Address noise as close to the source as possible. Use anti aliasing filters to match control loop execution. Filter minimally.
    However, noisy signal can add significant wear on control element so a PV filter might be called for. But it can become the dominant secondary lag. In which case I would not use derivative action.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Eugenio,

    Sorry for the delay, I was busy at the Emerson Global Users Exchange last week!  Did you make any forward progress on your application?  

    Good info from all the responders!

    It sounds like the valves you are using don't have positioners which means they will have a "dead band" (per ISA S75.25, the magnitude of reversal of the PID %OUT of the PID  required to produce a response) of at least 5% and could be as much as 25%.  Thus, your choice to add flow loop as the secondary loops for your temperature and level loops is good.   Though I prefer a high performance digital valve positioner (e.g. Fisher DVC) on all control valves,  a fast loop like flow "has a chance" to perform reasonable well without a positioner.   However, the tuning of the flow controller must match the process without excessive PV filtering.  A large filter like 20 seconds will set the dominant time constant for the typical flow loop and will require a slow Reset time of 20 or more seconds.  Thus, you will not get the fast response needed for good control.  1-3 seconds of filter time should be sufficient (if not, find out why) for noise rejection and the reset time will be on the order of 2-3 seconds but not smaller than the filter time.  Derivative action is used for significant secondary lags and is not usually used on flow loops.  For a tutorial on tuning self-regulating loops like flow loops, see my article in the ISA Intech online magazine at   https://www.isa.org/intech/201606basics/ .

    Temperature loops often, but not always, have "second order overdamped response and thus benefit from derivative action.  Sometimes that have an integrating response, often with a secondary lag.  See the following ISA articles for more information on tuning such loops.   https://www.isa.org/intech/201604basics/   https://www.isa.org/intech/201610web/ 

    It is rare for Level loops to need derivative action (you mentioned the use of derivative on the flow loops).  Level process most often have an "integrating" response which do not benefit from derivative action.  However, there are few cases like dearatior tank level and boiler drum level that can exhibit an "integrator plus lag" response which can benefit significantly from derivative action.  Again, see this ISA article for the integrator plus lag response.  https://www.isa.org/intech/201610web/

    I hope this helps!  Keep us informed on your progress and reach out with any additional questions!

    James