Emerson Exchange 365

I would not use a splitter block. I would use an override controller. When your "good" flow gets maxed out, the "bad" flow will make up the difference.

Lots of different questions being asked here. Let's take the one about what happens when one of the flows slumps. If the MASTER level loop's output is being split between 2 flow loops and one of the flow loops fails to provide enough flow to satisfy the level setpoint then the output will of course increase. The issue is that by having the splitter set up the way you are describing. only the second loop can try and respond to the increase in the output once the output has gone past 50% which it will do if flow 1 is limited. If there's enough capacity in loop 2 then the demand will eventually be met and the output from the level will stop increasing. Remember that the MASTER level loop doesn't know anything about the flows being used to satisfy it, it just knows that it is or isn't satisfied and responds accordingly.

Books On Line says that if one of the downstream blocks isn't in CAS then the Splitter goes to IMAN until both are in CAS. I don't see where it says what the Splitter's BKCAL_OUT does in this case. It says what it does if either or both of the downstream blocks is limited. I expect that since the splitter is no longer in CAS mode then the upstream PID block will also be forced to IMAN since it requires the downstream block to be in CAS or RCAS. You'll just have to build a simulated loop and test what happens on a down stream block being in the wrong mode.

In your scenario what would cause the AO block to leave CAS mode other than a failure in the I/O card/channel?

John, I think you could use a splitter block as you described. I would have to try it first to make sure. I'm pretty sure that as long as one of the downstream loops is in CAS, you would be OK (LIC would not go into IMAN).

I don't want people to think I believe every problem requires MPC, but this would be a good example where you could use either Predict or PredictPro. Predict would actually be a good solution. Your MVs would be the two flow loops. Your 1st CV would be the level and your 2nd CV would be the tieback of the pristine and pleasant flow loop, as a maximizing shadow CV. The controller would preferentially control the level with the pristine and pleasant feed, but would use the defiled and despicable flow as required if the other flow were not in CAS or otherwise limited. This is not really too different from using Predict for split range control as described by Greg McMillan and others in the past.

In PredictPro you would have a 2x1 controller and set the pristine and pleasant flow MV to MAX in the LP Optimizer. No tieback or shadow CV required, although you could easily add both loop outputs (actual valve positions would be best) as shadow constraints. If the defiled and despicable flow comes on too soon, you could also give it a MIN objective in the optimizer.

Either MPC approach would require 2 MV license, but setting it up would likely take a day or less. You could spend that much time mucking around with the splitter and you wouldn't have to worry about the dynamic response when the pleasant and pristine loop saturates prematurely.  The TSS for the level and flows would be very short and step testing both MVs could probably be done in half a day or less.  If you already have decent level and flow loop dynamic models previously, you might be able to skip the step testing altogether.

In reply to Bruce Brandt:

To clarify, as long as one of the output blocks downstream of the splitter is in CAS, the loop will remain in cascade and will not go to IMAN. The first downstream block to go to CAS, when both were out of CAS, will cause the upstream block to adjust its output via the BKCAL so that a bumpless transfer occurs. In this case, if Loop 2 is placed in CAS first, and say it was at 50% (150 GPM), this would cause the Level Loop to go to 75%. When Loop 1 is placed in CAS, its output will ramp to 100%, as long as the Level loop output was above 50%. This would depend on the balance time configured in the splitter and how fast the Level loop would integrate down.

The thin to be wary of here is if both loops are out of CAS, you would want to bring the first loop to CAS so that it does not bump, and loop 2 remains at 0% until there is demand. But the Level loop will continue to control as long as one flow loop is in CAS.

As for using Override control, that is typically done when one control valve impacts two or more variables, which have constraints on them. This problem is a splitter problem, though the MPC approach suggested by Lou may be a better alternative.

The challenge for the PID blocks is that the pristine flow appears to have variance and therefore non-linear response. The Level Loop tuning may be difficult to define. This will depend on how fast the closed loop response time needs to be. Level loops typically work better with minimal reset action in the PID or with PD control as the integration of the level error will cause cycling in series with the integral action of the PID.

The whole idea of cascade Level/flow is to improve the level control by providing a consistent volumetric flow response to the Level Loop output. The Pristine Flow controller will saturate his output quickly trying to satisfy the demand from the level loop, one that happens, the level must integrate through to the splitter transfer point before the second loop starts to contribute. In reality, the second loop needs to come online as soon as the first loop saturates. If the level can deviate until the output pushes to the second range, that might be good enough. I wonder if DBacker was on to something, in that this might be more of a Major/Minor valve control, where you only open the second valve when the first valve reaches a limit. I'm thinking that the two flow's should be coordinated to produce a more consistent volumetric flow so that the Level Loop output demand in GPM is met dynamically by the flow loop. So maybe the splitter should be after the flow controller, which is a faster loop and does not have the integration in the process. If the flow drops off, it would drive its output through to the second valve more quickly, maintaining flow. Display the two flows separately, but sum them as the input the Flow loop, and split the flow output in split range to the two valves. Hmmm.

If the pristine flow process gain varies, how will that affect the MPC model and the performance of the MPC? This gets back to how fast and how tight is this level supposed to function in closed loop control. Interesting problem though...

Andre Dicaire

In reply to Andre Dicaire:

Thanks to everyone for the helpful insights and suggestions. To clarify, the two flows in question are recycled & deaerated condensate (LOOP1) and makeup boiler feedwater (LOOP2) from our neighbors, which is not very good. We are controlling the level in what's effectively a steam drum (although the service is NOT a boiler), so the control needs to be fairly tight, say ±5% with a setpoint in the lower half of the span - allowing cyclones to function optimally without risking cavitation in the circulating pumps.

Only rarely will LOOP1 be capable of satisfying the entire demand, so typically the output of the level controller would be above 50% and placing a demand on LOOP2. So >90% of the time, a valve position controller would be idling anyhow. It's more the transition and the reaction to flow disturbances of the maxed out LOOP1 and mode changes that concern me most.

There are several other users of the pristine recycled condensate, one being the plant that makes Hydrogen for our process - a critical end user. Their demand is fairly constant, but there are also periodic users - like for spraying demister pads or even washing down the unit. So I already anticipate an "over ride" control on the total condensate returned to the drum - as these users kick in / out and the level in the condensate feed drum slumps, the LOOP1 flow will be curtailed. Otherwise I would do as Andre suggests (I think) and just apply the splitter to the two LOOP1/2 valves.

Since there's is already an override on LOOP1 flow (low select) which will curtail the condensate recycled, I worry about the operator comprehending what's going on. Maybe Lou's suggestion is the best alternative.

In reply to John Rezabek:

John, Whatever happened? Did you have any success with this?

In reply to Lou Heavner:

Lou, I already have an override on the "good" flow; the condensate (feed to the Deaerator) has a number of other users whose requirements must be met first, so the condensate tank level will take over the flow if the level in the (supply) tank starts to slump. That's the variable limit. So I was thinking I could use the "good" flow's "not selected" status to motivate the steam drum level to utilize the less desirable make-up BFW. The Deaerator is still being fabricated - looking at an April startup so we will see how it functions then.

I wonder how the "Not Selected" status feeding back through the splitter to the steam drum level controller will affect it . . .