Emerson Exchange 365
Search
Sign-In / Register
Site
Search
Sign-In/Register
Services
Products
Control & Safety Systems
Asset Management
Measurement Instrumentation
Valves, Actuators & Regulators
Fluid Control & Pneumatics
Electrical Components & Lighting
Welding, Assembly & Cleaning
IIoT & Digital Transformation
Industries
Chemical
Food and Beverage
Industrial Energy
Life Sciences
Oil & Gas
Power
Refining
Other Industries
Women in STEM
Events
Düsseldorf 2024
Immerse - Anaheim 2023
Grapevine 2022
Nashville 2019
San Antonio 2018
The Hague 2018
World
China
South Korea
Russia
Products
Control & Safety Systems
DeltaV Forum
Delta V Controller Limitation.
Forums
Blogs
Library/Resources
Members
Tags
More
Create New Post
Comment or Question? Become a member of this Emerson Exchange 365 group. Click here to join.
Recent Control & Safety Systems Discussions
Wei Sun
13 Sep 2024 4:47 PM
Lose VBA functionality from Operate to Live
10 Replies
Zohaib Jahan
11 Sep 2024 11:50 PM
Decommission and recommission RM100 Smart Switches?
5 Replies
dolatrec
7 Sep 2024 2:04 AM
Convert Wind Direction Degrees to Compass Directions
7 Replies
Ralph Kitts
6 Sep 2024 6:23 PM
CPU Carrier question
2 Replies
Benji_Kidmose
30 Aug 2024 4:26 PM
DeltaV - Epochalypse
2 Replies
<
«
3
4
5
6
7
»
>
Similar Posts
VIM and Delta V controller Limits
Delta-V Controller & System Limits
Limitation of MX Controller
MD Plus and SD Plus Controller DST Limitations
Where are the limits defined for AI Status OPTS "BAD if Limited"
Share
Answered
Delta V Controller Limitation.
Why is DeltaV controller Limited To 64 I/O Cards ?
All Responses
Answers Only
Andre Dicaire
In reply to
salehatiyyat
:
Every controller processor is limited in its Physical IO, it's processing power and its Memory, and how the system is licensed. DeltaV controllers are no different. Starting with licensing, DeltaV has chosen the IO subsystem as the primary system licensing component. We don't consider how you use the IO, how complex or simple the control strategies are etc.
One you have an IO count, you can design the IO you need. But you also have to consider where you put that IO as there needs to be available CPU to run the desired control. CPU consumption is based on the logic complexity, and the frequency of execution. A single module running at 100 ms consumes the same CPU as 10 identical modules each running at 1 second. The memory of a controller can limit the amount of logic that can be assigned, but the current ratio of User memory to CPU capacity in DeltaV controllers has taken Memory out of the problem (except maybe for very large Batch oriented systems, where memory must hold many Phases while on a few are executing at a time.
If CPU and Memory are not a constraint, you are limited to 1500 DST's, (IO Licenses) on DeltaV controllers (SX or MX) Over the years Emerson has released higher density cards, but the original 8 channel cards resulted in a maximum of 64 *8 channels or 256 IO in the original release of DeltaV. Later, we released the 32 Channel DI/DO cards, and added the 16 Channel SOE/DI card and 16 Channel AI cards. We also had 8 channel cards for DI, DO, AI, AO, Thermocouple and RTD cards, and the 4 Channel Multivariable/PCI card.
Enough with the history. The reason the IO is limited to 64 local cards is due to the address bus embedded in the IO Carriers. Each carrier has 8 slots, and so there are 8 Card selection lines. In addition there is a bank or carrier selection bus, where there are 8 more selection lines. By selecting a carrier, and a slot, the controller identifies a single card with which to communicate. The selection lines are passive connections with no switches or active components in carriers, giving them a very high MTBF.
so the limit is 8 carriers with 8 cards each, or 64 local cards. Why is the bus limited to 8 carriers? well the short answer is, because it is. As a said, the bus has 8 carrier selects. If you added a 9th carrier, the 1st and 9th carrier would become active at the same time, and that would result in their corresponding cards conflicting on the communication bus, and you would get no communication with any cards. The bus addressing is directly related to the order in which carriers are connected. Each carrier shifts the bank selection lines up so that the next carrier will be selected when its corresponding select line is set. Select line 2 becomes line 1 in the second carrier, line 3 becomes line1 in the third carrier, and so on. Each carrier is selected when it's "line 1" is set, and along with the slot selection, only one card on that carrier is actively communicating.
So the order of connection denotes carriers 1 through 8, and if a 9th carrier was added, its select line would go active when select bank 1 is set, creating duplicate addressing. The benefit of this is you have no moving parts in the form of switches to address the carriers, and you have one component that automatically addresses itself in the bus.
As for the limit of 64 cards, note that I said local cards. There is also the Remote Interface Unit that allows an additional 16 IO carriers to be connected to and M series controller, adding an additional 128 cards to the M series controllers IO capacity. The RIU sits on the DeltaV network and each of its 8 cards can be assigned to a maximum of 4 controllers to which the RIU can communicate.
With the release of S-series controllers, you can have up to 16 CHARM IO cards assigned to a Controller, in addition to the 64 local cards. Or 16 WIOCS, or any combination of CIOC's, WIOCS and RIU's to the S-series controllers. The M-series supports the RIU type remote nodes.
The theoretical physical IO capacity of a DeltaV controller exceed 3000 IO Channels, but you are ultimately limited by the DST capacity, and possibly the CPU to a lesser amount of IO. With a combination of 32 channel discrete and 16 channel analog cards, a typical IO mix on 64 cards can now exceed the DST license limit of the controller. Add CHARMS to this mix and you easily have more IO than the controller can process control strategies for.
One last comment. With S-series IO, the CHARM IO subsystem is physically separated from the controller, and each IO card can talk to up to four controllers. This feature delivers what I call Controller expandability. The separation of the IO hardware allows us to independently design and even install the IO subsystem for each unit or process module and to create an "IO Network" of up to 16 CIOC's for a total of 1536 IO channels. I can then assign 1, 2, 3 or 4 controllers to this network, or add control capacity, so that the delivered system has sufficient CPU to utilize all installed spare IO and spare capacity. This is also called late change forgiveness. Gone is the threat of overloading a controller with control strategies running faster than anticipated, where we have to rewire IO channels to a new controller and new IO cards. You simply add a controller to this section to the control system network and you instantly have doubled your CPU capacity for that IO.
I hope I've answered you question, but I also wanted to share how DeltaV controllers are not limited to 64 IO cards, and that the CHARM IO technology delivers a revolutionary approach to control system design: Start with the IO, and add controllers to meet your control needs. When I say game, you say changer, Game...
Andre Dicaire