Using PID to control two valves in series

[NXTenergy]

Looking for some insight on the best way to control a system consisting of two valves: 

a) One natural gas valve, for which the process variable is the burner temperature (air ratio is taken care of by a seperate blower motor/controller), and the setpoint is just desired temperature. 

b) DOWNSTREAM of that valve, and after the air and gas are mixed, I have another valve that goes to a second, smaller burner. 

The issue is that while the first burner is very stable on its own using simple PID control, when part of the gas/air for it is re-routed to the second valve, it cools off so that the main gas valve (a) must open more, but then the second valve (b) will overshoot temperature unless its valve closes, causing the first (a) to heat back up, etc. So basically, the two valves are fighting one another and due to the touchy nature of the gas valve (a), it takes a very small valve (temperature) change in the second burner (b) to really throw off the control to the first. 

Right now I can get the two to stay reasonably close using two seperate PID loops controlling to the temperatures of the burners, but only if I change heat loads very slowly. Working on fine-tuning the anti-windup characteristics on my loops right now to get them more stable, but any suggestions on a better way to do this would be very helpful. 

Thanks.

[Blokk]

hmm, interesting problem 🙂 Unfortunately I am not an expert at all in control theory, usually I use single separate PID loops, and a simple closed loop Ziegler-Nichols tuning just gives me what I need...

Maybe just a silly idea, but I am thinking about a small (?) hardware change instead of software solution:

as I understood your explanation, the smaller valve creates disturbances in the gas/air supply line, so the larger valve burner starts to be out of control. You should deplete these disturbances in time. What about to put a buffer vessel between the smaller valve and the gas supply line? So when the smaller valve "requests" some gas, it does not come "directly" from the gas line (which has a rather small volume), but from the vessel. This could act as a kind of low pass filter maybe? So the two control loops would be more separated from each other, not too closely "wired" via the gas supply line...

[johnsold]

The system controlling valve (a) becomes unstable when a portion of its output is diverted by (b) to a place where the process variable for (a) cannot respond to the change.  A control system which does not know what is going on has difficulty providing good control!

So it sounds like you need a new process variable or perhaps more than one.  Does the pressure in that downstream pipe vary in a consistent manner when valve (b) is opened (for a given setting of valve (a))? A control alogorithm which accounts for both the burner (a) temperature and the pipe pressure might work. Similarly, the setting of valve (b) - which you already know - might be the other required input to the valve (a) controller.

Also look at feedforward systems.

Lynn

[NXTenergy]

Blokk: I like the idea of adding a sort of disengaging vessel, but I believe this problem can be solved with the software in this instance since typically, changes in load and temperature are on the order of minutes rather than seconds (or less). 

Lynn: I am seriously considering a feed-forward system that multiplies the output to valve (a) by the actuation of valve (b) times some gain factor.

I've also been trying to implement a sort of deadband or integral anti-windup, but to no avail. It seems that if you try and do it as NI recommends in this article it resets the entire PID loop (all values) not just the integrated error. Why??

As you can see if you try and run the code I've attached, when you get to the "deadband"--within two degrees of setpoint--the output immediately goes to my minimum valve setting of 18. Obviously this wreaks havoc on the gas valve. I could "trick" it by setting the scaling on my valve to actuate to the default -100 to +100 setting in the PID but that seems silly. 

Alternatively, is there a "best way" to just freeze the output of the PID once it's in the deadband till the temperature gets outside that range? That would probably work just as well. 

Thanks. 

[johnsold]

You might try just re-initializing the PID VI one time when the dead band boundary is crossed. Implies followed by Not may do what you want. The boolean lines entering from the left and exiting to the right connect to a shift register on the loop.

Another option is to make a copy of the PID VI with a different name and save it to a new location. Then open the block diagram and modify what gets reset. As you guessed, it appears to reset several things. You could change it to only reset the integral. It uses several uninitialized shift registers to save values from the previous call so you could use that information to minimize the disruption when you do a reset.

Lynn

[nathand]

---

NXTenergy wrote:

Alternatively, is there a "best way" to just freeze the output of the PID once it's in the deadband till the temperature gets outside that range? That would probably work just as well.

---

Don't know about "best way" but I would use the PID Advanced block for this. It's just the standard PID except with a couple extra inputs, two of which are for manual control (a disable it, and a value). The important thing is that it supports "bumpless" transfers between manual and PID control, so when you switch back to PID from manual, the value adjusts smoothly rather than jumping suddenly.

For your situation, once you're in the deadband region, you'd keep feeding the previous output back in as the manual value.

I've generally found it convenient to wire the the "auto (T)" and "reinitialize? (F)" inputs to the same source, but negating one of them, so the PID reinitializes anytime you're in manual mode. This clears any integrated error. When you switch auto back to true to reenable PID control, reinitialize will be false, and the bumpless transfer will work properly with no existing integrated error. It's possible this isn't actually necessary, I haven't looked at the internals in a while and they may have changed, I just remember it was convenient at some point so I've maintained that habit.