Recent Control & Safety Systems Discussions
Similar Posts
How to use bulk edit for assigning charms ,SLS DSTs to IOs ?
Assigned new DO Isolated VAC & when testing on false in logic at charm still reading present VAC?
Assigned new DO Isolated VAC & when testing on false in logic at charm still reading present VAC?
Delete an assignment of control module
HART- Having trouble assigning field device parameters in Control Studio
Share
  • Not Answered

CHARM IOs controller assignment

Hello to all, I just needed some help regarding the CHARM IOs assignment to a controller.

Here's the setup:

I have CIOC-02 assigned to CTLR-01 and the CHARMS in it are all assigned to CTLR-01 (it has CHARM Baseplates 1 to 4). Now, we have added CHARM Baseplate 5 & 6 for a new project but this is in a different Line (We have Line 2,3 & 4). We wanted to assign the CHARM IOs in baseplate 5 & 6 to CTLR-02 (another controller). Is it possible or ok to do that even though the main CIOC-02 is only assigned to CTLR-01?

We have 2 CIOCs that are assigned to both CTLR-01 & CTLR-02, do I have to that as well to CIOC-02 to avoid issues? Thank you in advance.

dolatrec

17 Replies

  • Jesse Delanoy
    Yes you can assign CHARMS I/O from a single CIOC to multiple controllers. Look in BOL for the topic "Capacity limits for the I/O network and wireless I/O network" to see the limits. If I recall correctly a single CIOC can serve up to four controllers.
  • dolatrec

    In reply to Jesse Delanoy:

    Thank you Jesse for the reply, I'll check BOL as well. We just wanted to do that to distribute the load as well since our CTRL-01 is around 48% while CTLR-02 is a bit higher. Thank you again.
  • Andre Dicaire
    Perfectly fine to assign IO as suggested. As far as the controllers are concerned. Each is assigned both CIOCs and a subset of their CHARMS. This consumes two of the possible 16 CIOCs each controller can be assigned.

    The original purpose of allowing a CIOC to be assignable to four controllers was to separate IO design from controller CPU capacity. With SX and SDPlus controllers available in v11, contrôle strategy design would often result in CPU being consumed before IO capacity could be realized. This could lead to costly redesign of IO assignments and related Cabinet and marshalling changes. The CIOC design allowed a set number of IO to be designed and an ability to add controller CPU as needed to implement control, up to four times the original capacity of a single controller.

    A secondary benefit is realized that allows multiple controllers to share an IO node so the a user can deploy related control strategies in dedicated controllers while optimizing the design of the IO network. Redundant IO cards and networking deliver high availability of IO.

    The distributed deployment of CHARMS allows for reduced infrastructure costs and support virtually unlimited IO capacity over the Ethernet/fiber infrastructure as compared to traditional home run cabling. This shifts the design burden off the E&I buildings as IO is installed close to process equipment, and adding IO does not require available space in the E&I room.

    With the arrival of the PK controllers, the CPU concerns have shifted. All PK models have the same CPU and Memory, which is close to four times that of SX/MX.

    Back to the reason the CIOC supported “Control CPU expansion” an SX controller was typically limited to 600 to 1000 IO with CPU free time falling below stated minimum of 28 %. On a project that specified a minimum of 40% expansion, a controller had to be sized for 360 to 600 IO. Even after doing this estimate, the actual project CPU consumption was not known until controller configuration was complete and in FAT. To avoid failing to comply, the allowed IO per SX controller was often sized for 500 IO with capacity to do 700 max IO.

    A PK750 delivers four times the CPU as an SX and a Known Design limit of 750, which all but ensures no late changes and eliminates unpredictability in CPU capacity. Two PK750 controllers are marginally more costly than one PK1500, but deliver twice as much capacity and up to 32 CIOCs vs 16. Adding a PK1500 spare controller vs. Spare PK750 makes using PK750 the right choice for most applications. A PK100 or PK300 can be deployed for point applications, especially ones with low IO counts but high CPU.

    Understanding the capabilities of DeltaV controllers and CHARMS can provide a solid foundation for Project Certainty while delivering late change forgiveness. These capabilities don’t negate the need for good engineering decisions for the system.

    Whether you assign one channel or 96 channels of a CIOC to a controller you consume 1/16 of that controllers CHARM capacity. CHARM IO allows us to design the system IO to match the process instrumentation, build cabinets, install and commission the IO without any installed controllers. The number and size of controllers can be deployed to support the control strategies, knowing the IO assignments can be refined with zero physical rework. But only if you don’t consume these options unnecessarily.

    Andre Dicaire

  • dolatrec

    In reply to Andre Dicaire:

    Thanks you so much Andre for this helpful detailed explanation and information regarding controllers and charm limits/capacities. We do have 2 CIOCs that are assigned to both controllers so I was just confused initially whether I have to do it in other CIOCs as well. Thank you again.
  • dolatrec

    In reply to Andre Dicaire:

    This is the controller performance index we have in CTLR-01 (SX)

    While this is our CTLR-02 (SQ)

  • Douglas Crowder
    I believe that a power cycle is required on the CIOC after adding new baseplates. That is the only way for them to be picked up.
  • dolatrec

    In reply to Douglas Crowder:

    Hello Douglas thanks for the reply. For power cycling I'm not sure. We did not power cycle the CIOC and did some loop checking for few IOs like XVs and we were able to stroke it normally, no issues. We just did a download of the full charm (baseplate 5 & 6) from DV Exp (show all charm option is selected) and everything went well.
  • Andre Dicaire

    In reply to Douglas Crowder:

    Adding baseplates online is not supported. First, removing the terminator flags an integrity alert. While the terminator is removed, the bus is exposed to noise and reflections which could disrupt communications. There a lot of variables for this and in many cases no abnormal effects are experienced(in a lab environment like my demo system). On a production system we have to be more careful and since something could happen without the terminators in place, online addition of baseplates is not supported.

    Secure the process and ensure operations are aware and what loops are potentially affected. Each situation needs to evaluate what steps to take. Best to do when process is down or is a stable passive state.

    There is no electrical risk to adding baseplates with the CIOC under power. Once baseplates and terminator are installed operation can be restored as CHARMs can be added on line.

    A power cycle is not required. Each baseplate holds an address plug which defines the address range of the contained CHARMS. These plugs are not connected to the CHARM communication bus. When a CHARM is installed it derives its address from its physical position on the baseplate based a passive resistance bridge driven by the address plug. The CHARM announces itself to the CIOC and if the address is available, the CIOC recognizes the new CHARM. If the address plug is a duplicat of anothe baseplate, and a CHARM already exists in the same slot, the new CHARM is rejected. Its LED will indicate an issue.

    The only concern is to ensure the address plug is not a duplicate. In the case where duplicate address plugs are installed, new CHARMS are rejected. If a power cycle is performed with duplicate address Plugs, it is impossible to determine which CHARMS will get recognized. Make sure address plugs are unique and commission the CIOC to ensure all CHARMS are properly addressed.

    Andre Dicaire

  • dolatrec

    In reply to Andre Dicaire:

    Thank you so much again Andre for this detailed response. In our case the production was down and the CHARM Panel power was ON when we added the CHARM Baseplate 5 & 6 (removing bottom terminator, adding bottom extender cables & adding top charm terminator).

    The CHARM Panel we have is small so we can have up to 5 CHARM Baseplates on the left side and from the right we started with baseplate 6 so we added a bottom charm extender. Thanks for the heads up regarding duplicate charm address plug, we'll take note of that as well.

    It did happen to us one time when we added another CHARM base when the production was online, good thing nothing happened, but we'll keep a note of your advice to avoid it as much as possible.
  • Douglas Crowder

    In reply to dolatrec:

    Andre had a better answer. Online adding baseplates not recommended / supported. We always put all 8 baseplates in the enclosure (if enough space) to allow for future online expansion.
  • dolatrec

    In reply to Douglas Crowder:

    Yeah I agree, but unfortunately in our case it wasn't added when the panel was commissioned. But we'll keep note of that advice next time we are planning to add more we'll make sure the production is down or in a stable passive state.
  • Andre Dicaire

    In reply to dolatrec:

    Curious to know what the IO count on these controllers:
    # OF CIOCs
    Total IO
    HART Channels
    CIOC update rates 50, 100, 250(default), 500 ms.

    Andre Dicaire

  • dolatrec

    In reply to Andre Dicaire:

    Hello Andre,

    is there a way for me to see all these things in one page?

    we have 16 CIOC
    DST 966
    44 registered HART tags
    CIOC Update Rate are set to 250 default (there's 1 CIOC set to 500 ms not sure why but it was set like that already)
  • Andre Dicaire

    In reply to dolatrec:

    Is that per controller or total?

    From a Control Capacity at 48% on an SX which is rated to 1500 DST. If that controller has say 600 assigned DST's, you might expect it could get to 1200 DST's before CPU expansion falls to 0%. But CPU consumption is based on module "complexity" and Execution rate, not jus straight up DST counts. The other controller has 60% CPU capacity, so expecting it has fewer DST, but that is based on assuming a consistent distribution of IO types and control Module algorithms. I think there is a bit of a misnomer in the index diagnostic, indicating that a higher Index is better. The controller is not built to provide available free CPU, but for you to use the CPU. An index of 2 is just as good as an index of 5, in my opinion. a %CPU capacity of 1% means there is no room for expansion. a Value of 0% tells you it has exceeded rated capacity and you don't know by how much. Control On Time may still be at 100% but you are unable to know at what point you may experience detrimental effect. The CPU % capacity is an indicator of how much more control this controller can perform, generally measured in IO points, but actually consumed by module logic and execution speed.

    The CIOC consumes COMM Capacity loading. There is a set base load for each assigned CIOC. and an additional load relative to the assigned CHARMS. HART CHARMs handle more data wrt HART Variables and HART connection of AMS to the devices (which is typically one channel at a time, based on technician activity). There is also communication from the controller to the consoles. The controller is designed to limit the workstation (unsolicited) communications to prevent monopolizing the network. As you add more control modules with more IO, both %CPU and Comm capacity are affected. Adjusting the update rate is one way to manage the IO communication loading.

    The diagnostics indicate your controllers are about half full along with the communication load. You have 966 IO across two SX Controllers, with 5% of the channels being HART. Analog HART Inputs will typically be the more burdensome channel type. To me this looks pretty typical in loading. If you have IO on every CIOC going to both controllers, your comm loading is higher than if you had dedicated CIOC's to each controller (i.e. 8 CIOCs to Each controller.) But there is nothing wrong here. I would describe this as a single IO Network made up of 16 CIOC's supported by two SX controllers that share IO, giving you the ability to reach 100% utilization of the Physical IO.

    If you look in Explorer under the controller, you see each controllers assigned CIOC's and if you look in Licensing allocation tool, it will show number of DST's for the assigned IO cards per node. You can also count the assigned CHARMS under each assigned CIOC of each controller.

    Andre Dicaire

  • dolatrec

    In reply to Andre Dicaire:

    Hello Andre,

    It is total. Yeah some of the modules we tried to reduce the module execution rate like the temperature monitoring to 3-5 seconds those that are not critical, and we tried to avoid as much as possible inter controller communications and making sure there's no unresolved ref. CTRL-01 is SX while CTRL-02 is SQ. We do have a plan to change SQ to SX this coming October 2024 to increase the capacity because we are adding another production line. Line 2/3 in CTRL-01 and Line 4/5 in CTRL-02, actually they are in simplex right now so we are also making it redundant.

    We checked the Assigned IO under controller and there are CIOCs assigned to CTRL-01 than CTLR-02

    Here's our IO license demand

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.