Recent Control & Safety Systems Discussions
Similar Posts
Deleting Multiple Parameters Simultaneously from an Operation in Recipe Studio
Control Valve Cv and PID flow control
Problem with vacuum control valve PID loop
How do I get a PID control valve to react quicker?
PID Control Opts
Share
  • Not Answered

One PID Controller controls 10 valves simultaneously

May I know what is the best approach in controlling 10 valves simultaneously using only 1 PID controller?

Can I use 9 splitter blocks to cascade the signal to the 10 AO blocks of the 10 valves? 

Or is there a better approach other than the splitter block?

Rein

11 Replies

  • Gareld Butler
    First, could you further explain how this PID is controlling 10 valves? Is it a progression with the next valve opening/closing after the previous one has fully opened/closed? Are all 10 valves actually controlling at once or is just 1 out of 10 controlling at any given point in time?
    Splitters might work but you need to "gang" them so one splitter feeds two splitters which feed four splitters, etc. If the number of valves actually in control at one time varies, you may also need to look at adjusting the controller gain based on the number of valves currently operating.

    Gareld Butler

  • Rein

    In reply to Gareld Butler:

    The PID controller will throttle all the 10 analog valves (0-100%) at the same time based on the analog input.
  • Andre Dicaire

    In reply to Rein:

    As Gerald points out, having a varying number of valves on a PID block can affect the process Gain and that can negatively impact loop performance. So there are a few concerns/considerations that need to be understood before a recommendation of how to connect these values could be made.

    One issue that can come up is how to connect the Bkcal signal from all these values. With the splitter block, you can expand the PID out signal to 10 signals connected to the CAS_IN of the ten AO Blocks, and the AO/BKCAL_OUT signals to there respective splitters and so one. with all the valves out of CAS, the PID will go to IMAN and initialize with the first valve that comes out of CAS, and the Splitters will use their ramp function to bring all the other valves to the PID OUT value as they are placed in CAS mode.

    So you have to look at how the AO blocks will be operated/managed and account for that in your logic. The simplest solution is to disable the AUTO and MAN modes and only ever operate these valves as a tandem set via the PID block. But having an AO block and not being able to set it to say MAN to test a valve or possibly take one out of service may not be what you want.

    Another way is to wire the PID directly to all 10 AO blocks, and use the TRACK Output to manage the PID OUT based on some specific logic, i.e. minimum number of AO blocks are not in CAS. By not connecting any BKCAL signal to the PID, it will never go to IMAN.

    You could use a CALC block to manage the PID OUT to AO CAS_IN and generate a BKCAL signal to the PID block based on specific logic to get the behavior you want. You can embed this in a block in the module so the diagram is clean and efficient, and use a combination of blocks in the embedded block to manage the code. Could look like a 10 output splitter, so it is easy to use, but it does exactly what you need.

    Another thing about cascading splitter blocks. When you take an AO out of CAS, the module must execute multiple times before the bkcal signal makes its way back up to the upstream PID block. Similarly, when you return the AO block to CAS, the module executes multiple time as the Bkcal status and value are passed to the previous block. Using only splitters, you would need thre layers of splitters to get to 8 outputs, and another layer on the last splitter to get to 10.

    The splitter gives the ability to alter the response of the inputs for split ranging. You don't need this feature, and if all valves must operate together in parallel, you will likely be better off with a simple logic and manage the initialization of the loop manually. If that's the case, you don't really need the Bckal signals and so you don't need the splitters. Just be sure you've considered how the valves are to behave is taken out of CAS and how they behave when placed back in CAS.

    If you write to the target mode of the AO blocks in a CALC block just prior to the AO blocks in an execution order, you can lock the AO blocks into your target mode and prevent them from being set to AUTO or MAN, and then you can control when this is allowed. Like if PID mode.actual > MAN Then AO/MODE.TARGET :=CAS.... Or you might just want to do a one shot force to CAS when you cycle the PID Mode from MAN to AUTO or CAS. That would allow individual AO blocks to be manipulated individually or locked at a fixed value. All depends on how much flexibility you need and how the process Gain would be affected, and whether the PID block would be able to work with AO blocks out of automatic control...

    Andre Dicaire

  • Rein

    This is what I did. The OUT of each Splitter will be connected to the AO. Then the Bkcal_out of AO will be connected to the Bkcal_in of each Splitter.

    Is there any other Function Block that I could use to simplify this?

    :

  • Gareld Butler

    In reply to Rein:

    One of the problems with the way your back calculates works is that, as Andre pointed out, it takes multiple scans before the back calculate from some of those outputs will ever get back to the PID block.  In the case you show, it will be 10 scans before BKCAL_IN9 or BKCAL_IN10 get back to the PID.  If you layer the splitter blocks, as shown below, it takes no more than 4 scans for BKCAL_IN1-4 get back to the PID1 block and 3 for the rest.

    Machine generated alternative text: C I_scADA130 ICAL_OtJT J OUT r OUT_I F e 'CAL_OUT SPLTR SPLTR8 OUTI SPLTR TRI SPLTR SPLTR2 aKCAL_lN1 BKCAL_ SPLTR4 OUT_t •ZAL_OUT SPLTR SPLTRS o UT_I BVCRL_OUT SPLTRS OUT_t d "CAL_OUT SPLTR SPLTR9 r "CAL* -2 OUT_I r t KAL_OUT I— CAS_IN aKCAL_IN3 OUT_I OUT BKCAL_INS 3KCAL_lN6 BKCAL_N7 BKCAL_INB SPLTR ouT_2 BECAL_OUT BKCAL_1Ng BKCAL_NI O cgS_lN OUT_I OUT_2 B PCAL_OUT SPLTR SPLTR7 OUT_t - o UT-2 pcAL_oUT OUTB COTIO

    As Andre said, you may want to simplify this by computing your own back calculation to the PID rather than run through all of these splitters.

    The other thing I noticed was that you have the interlocks tied to to PID.  I assume each of these outputs might be on different lines where there might be different interlock conditions tied to each line.  If that is the case, you may want to set up interlocks for each of the AOs instead and let the backcal tell the PID if all if them are interlocked or limited or in the wrong mode.  If they really do all have the same interlock conditions, never mind my comment.

    Gareld Butler

  • Gareld Butler

    In reply to Gareld Butler:

    It looks like the editor did not like the picture I inserted.  Let me try again.

    Gareld Butler

  • Rein

    In reply to Gareld Butler:

    If in case one of the valves goes into IMAN or OOS, will this configuration affects the other valves?

  • Michael Krispin

    In reply to Rein:

    Can say in both approach, your serial or Garelds parallel (which I also prefer), a valve not in CAS mode will not affect the PID or other valves, because you get always on the second input another good BKCAL_IN value. What it means for your process is another point. Since you don't show a process flow diagram, no one here can imagine how that control (Flow/Pressure?) shall work.
    Best Regards, Michael
  • Andre Dicaire

    In reply to Rein:

    Thanks for the configuration example Gerald, that is what I was thinking.

    As long as there is one good BKCAL connection, the PID will remain in its target mode. The flip side is that if for some reason you have all the AO blocks in a mode other than CAS, and you then place one in CAS, the PID will align with that AO and transition to the TARGET mode, and as you bring other AO blocks to CAS, they will ramp to the defined control signal based on the Splitter blocks ramp rate. For your application, with all valves 0-100%, things will work rather predictably. In a split range application, if you bring on the upper range valve, the PID can synch to an OUT value of 50% to 100%, and when the lower range valve is placed in CAS, it ramps to 100%, because that's what it does and you asked for it.

    The point is that you have to carefully consider the abnormal operation conditions. As in with most complex strategies, the error handling can quickly become more complicated than the primary control scheme. The BKCAL mechanism is intended to facilitate synchronization of upstream blocks (PID) to downstream (AO or SPLITTER or PID for example). With 10 parallel downstream blocks, maybe you don't have to worry about this via BKCAL.
    - Will you ever operate this control loop with all 10 loops out of CAS? If not, then the BKCAL synchronization will never come into play. Why worry about it.
    - What if all 10 AO blocks go to IMAN due to loss of communication with the IO card(s). Very unlikely, but you would want to prevent the PID from winding up, especially if you've configured the AO blocks to hold last value. You can use the Track feature of the PID to handle any abnormal conditions, like, set a minimum number of Good AO signals to allow the PID to run in Auto. If the number of AO fall below this, you can force the PID to MAN and hold the output, letting the Operator still control the remaining valves' positions. Or if no valves are in CAS, force the PID to track to 0.
    - what other conditions do you have to consider? Hmmm.

    It's hard to imagine that a PID loop would operate adequately with one AO block if it was tuned with a process response from 10 AO signals. And vice versa. You might need some gain scheduling based on the number of Valves in CAS.

    You'll need to consider all this, and keep in mind that the Splitter function will keep the PID in AUTO even if only one valve is in CAS. I would say it was not designed for such an expanded array of Outputs, so it may not be the right solution for your problem.

    Andre Dicaire

  • foxriver
    What I have done in the past is use the Bias and Gain block. Setup one for each valve and bring the the output of the PID as the input of the B&G. This way you can have independent control for each valve in case you need to tweek the response of some individual values compared to others or just want to run some in manual will others are in auto.

    Dave
  • Jason.Brumfield
    If it were me, I would make 11 separate PID loops utilizing an external reference for the PV & setpoint to a master module. That way I could put any given one in MAN for valve maintenance activities & if the loop parameters, valve sizing, performance, etc had any variability, you could tune them independently.

This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

User Groups | World Areas | Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2022 Emerson Global Users Exchange. All rights reserved.