1) SX controllers define DST limit of 1500 I/Os. Also it defines max of 64 traditional I/O cards on local carrier + 16 Remote I/O units. Also it can handle 16 CIOC (16x96=1536 CHARMS). What if I want to use combination of all above configurations? Then still my DST is limited to 1500 I/Os. If I want to load my controllers to 50% as per client's requirement with avg scan time of 500ms, then what should be my upper limit of single SX controller in terms if DST? can i derive no. of controllers based on above inputs if I know total I/O count in project? module scan time is configurable from 100ms to 60 sec. so whether keeping 500 ms for all I/Os will load the controller more? how the loading of controller can be determined based on I/Os, scan rate & max loading requirement (say 50%)?
2) Can i use CHARMS for closed control loops/interlock action or generally client prefers to use it for open loop monitoring I/Os?
In reply to Maarten van der Waal:
You can check this whitepaper about CM execution, might be useful: www2.emersonprocess.com/.../WP_controlmoduleexecution.pdf
Also you should get the Load Estimator Utility to check how much your configuration will load the controller.
As Maarten points out, the loading of CPU is dependent on your logic complexity and speed of execution. The DST limits are hard limits applied in the database to set expectations of what each controller can do, but in the end, the real limiting resource for control becomes the controller CPU.
There are also tested to limits for the number of modules. These are soft limits and not enforced. But typically, you have fewer modules than you have IO. When serial data is integrated, the Module count often exceeds the DST count. Note that if a control module uses serial data or native IO data, it still requires CPU, so the CPU load is based on modules and their complexity, not necessarily DST count.
You can mix and match any IO for a controller, provided you don't exceed the number of DST's the controller supports. (750 or 1500).
You can certainly use CHARMS for closed loop control and interlocks.
As for predicting the number of controllers, you need to know how much CPU your control modules consume. The overall load can be estimated with the Controller Load Estimator tool, but ultimately, you need to know what each module type consumes. A module has a CPU load and a memory load. With Continuous control, you will not need to worry about Memory. Most projects use a known Module library and as a result can accurately estimate the loading on a controller by defining how many of each type and how fast they will be called upon to execute. If you execute twice as many modules, your loading doubles. If you halve the execution time (from 1 second to 500 ms) your loading doubles.
THis brings me to the question of why 50% loading on the controller? This is a standard approach that is used during system design, and is meant to assure there is enough CPU available in the controller if any or all of the spare IO capacity is required. If the IO cabinets and marshaling cabinets are designed to host say 1000 IO, but the controller is full when only 750 IO are connected, the remaining space in that cabinet is unusable, wasted space. So we typically see installed spare and expansion spare account for 30 to 50 % of the cabinet space, and the controller having 50% CPU capacity reserved for this.
This means we have double the number of controllers we need for the planned size of the system. And this increases footprint, because we add spares everywhere in case we need them, but most will not be used.
Another challenge with conventional IO is that I need to know the loading on each controller before I can assign its IO and finalize design of the cabinets. This impacts schedule and if I get it wrong, I can overload a controller. Good thing I only loaded to 50% during design...
With CHARMs, these issues are eliminated. First, the IO are not physically bound to a single controller. Rather than determine controller loading, you can focus on designing the IO cabinets and marshaling based on the process units. Later, you will assign the IO channels to the controller that hosts their control modules. I can add another controller if I find one controller is exceeds my loading limit. But I can design the IO cabinet and ship to site, even before controller configuration has begun. And I know I can use 100% of the IO capacity.
Now that I have CHARMS installed, I don't have to worry about controller loading, because I can easily assign control to a new controller without rewiring a single channel. I certainly can choose to use 50% as my loading limit, but if footprint and cost are important, you can cut down on both by using more CPU for the project. If later expansions require more CPU, you can add them at anytime to use all the IO space in your cabinets.
So, yes you can mix IO types on the same controller, but if you use CHARMS, you get Redundant IO MTBF/availability for all IO Types at no extra cost, you get increased usage of installed IO Space because you can always add controllers to increase the control capacity of the system, without touching installed IO wiring. In other words, running out of controller CPU does not mean you cannot use remaining spares in a cabinet.
Andre Dicaire
In reply to Andre Dicaire:
Thanks Andre. Your detailed elabotation helped.The main worry for me that we are doing basic engg & do not have sufficient inputs about amount of programming stuff/ logic requirements for the project. Shall try to get it from other sources.... Any how you have answered to my query & i can extract from it the overall concept about loading, no. of DST, etc.. So thanks & keep replying....it helps.....