PID derivative at saturation


#1

I am looking for suggestions to the following issue I have ran into using a PID with a derivative term.


[B]Background[/B]

This is for controlling supply air temperature using a thermo-electric actuator. It is controlled by a TPO output which varies the amount of power to the actuator to melt the correct amount of phase change material so the valve will be at the correct position to flow the correct amount of water (hot water in this case) to control the discharge air temperature - it was a fun challenge. It’s like controlling the movement of a wet bar of soap by changing the amount of grip on it. A normal person would resort to two position control for these small fan coils, but I’m not normal.

[B]What I am seeing happen[/B]

On the attached image, I have the actuator output limited to 50% to demonstrate what happens at saturation with a derivative term.

The top graph is the supply air (discharge air) temperature which is blue and setpoint which is yellow. Each of these are the input and setpoint for the PID, respectively.

The bottom graph is the TPO/PWM output % to the actuator in pink. The dark line is the graphing utility calculating the derivative of the discharge air temperature - ignore that line.

When the PID input rises above the setpoint, the integral term begins to lower as it should. This lowers the PID output which will eventually lower the PID input through the process. When the input begins to come down, the derivative term does it’s magic and increases the output. If the derivative happens to increase the output to saturation, then the anti-integral wind-up feature recalculates the integral, so we start all over again until the error is large enough for the integral to overcome any derivative disturbances.

[B]Options?
[/B]
I probably could have a smaller derivative term which would reduce the magnitude of the overshoot, but not eliminate it, but the D term I am using now works well other than at saturation. Right now, I’m leaning towards phasing out the D term when approaching saturation, but wanted to see if any of the smart people on here had any other suggestions.


Configuration PID
#2

My names Ben and I’m normal… Now that we have that out of the way…

Couple of questions for ya Philip…

[B]1.[/B] Really? Your varying the setpoint? Why? The discharge air temperature should be constant? Not variable? What am I missing here that helps me understand why the setpoint to the PID would be changing?

[B]2.[/B] The actuator… Does it have a micro-switch to indicate closed (or open). In other words, do you have any data that might show it’s position or state?

[B]3.[/B] What type of PID algorithm are you currently using?

[B]4.[/B] What are your current values for p, i and d?

I am really interested in the set up, the variable set point has me all excited. You don’t see that very often.


#3
  1. These are small four pipe fan coils anywhere from 7,000 to 48,000 BTU/hr. I adjust the supply air setpoint based on space temperature.

There is a PI loop for the space temperature which cascades it’s output to the setpoint of this PID.

  1. No feedback from the actuator - discharge air is as close as I get.

  2. ISA

  3. Screenshot:



#4

I use the same setup in my refrigeration application. It works best if I use refrigerant temperature (or hot water in your case) as feedback to the second PID. I typically don’t use any derivative in that application especially when using discharge air instead of refrigerant temp. I also use Type C PID. It seems to be easier for me to tune in my application.


#5

I don’t think I’ve used a velocity PID before, I’ll give it a shot on one of the units and see how it does.

Thanks!


#6

dgerdts,

I tested this on one fan coil and since the velocity PID doesn’t keep a running integral total, I don’t get the (bad) behavior I was seeing with the ISA algorithm, so this looks like a good solution. It’s also nice being able to change tuning parameters with out bumping the output, or having to switch back and forth from manual to auto.

I’ll have to rework the feed forward, as it works completely different on velocity, but that isn’t a big deal.

Thanks again - nice and simple, glad I reached out.