I’ve always seen the promise of participation in online communities and LinkedIn groups as a way for process automation and instrumentation folks to share knowledge, but leave it available for others with similar questions at a later time. While email is a problem-solving tool, it is limited to those in the distribution and not discoverable.
As an example, I’ll use a very dynamic discussion going on in the DeltaV group in the Emerson Exchange 365 community. Here is the original question, Behavior of Cascade Master when its output goes to a Splitter block:
I have a new problem to solve and was interested how the solution I’m considering will (or won’t) function.
First, I am thinking I can configure a “Splitter” block in the engineering units of the slave PID blocks (which is the same for both – GPM). If this can’t be done – please comment.
Assuming that’s not an issue, I am wondering how the loop will behave: I am maintaining a level with two different flow controllers. I very much prefer that the pristine and pleasant flow from LOOP1 is fully utilized and maximized before beginning to use the defiled and despicable flow from LOOP2. However LOOP1’s maximum may not always be the same – under certain conditions, it may fall short of its setpoint by a large margin. So if my “Master” level controller output is spanned 0-600 GPM, and the first 0-300 is all directed to LOOP1 as its setpoint, after which 301-600 is directed to LOOP2 for the remainder, what happens should LOOP1 start to slump or become “limited”? Will the output of the MASTER increase to make up the difference?
What happens if one of the slaves – especially LOOP1 – isn’t in CAS? If the other slave is in CAS, will the level control still function or will it go back to IMAN?
If you have any thoughts about a simple function block solution to this challenge I would welcome your advice. I know I could “roll my own” splitter in a CALC block, but I’m not as proficient at all the statuses for master-slave handshaking as I would like . . .
Within around 30 minutes, Emerson’s Denis Backer answered:
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.
Shortly thereafter came the next thoughts and clarifying questions from another community member:
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?
Emerson’s Lou Heavner offered an alternative consideration in using the embedded model predictive control capability in the DeltaV system [hyperlinks added]:
CAS, you would be OK (LIC would not go into IMAN).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
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, ax 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.
In PredictPro you would have a 2×1 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 of them 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.
All of these thoughts and ideas are being crawled by the search engines for the next person who is trying to solve a similar problem. I imagine many more thoughts will come in before this thread is done and the person who submitted the comment can flag which way answered his question.
If you have any Emerson Process Management technologies or services provided at your plant or production facility join the Emerson Exchange 365 community and the applicable groups in the areas of Solve & Support, Operate & Manage, Measure & Analyze, Final Control & Regulate and Industries.
Update: As predicted, there are more great ideas going in this thread!