Recent Control & Safety Systems Discussions
Similar Posts
VIM and Delta V controller Limits
VIM Network switches from active to standby and vice-versa intermittently
VIM CONFIGURATION FOR POWERFLEX 525 WITH DELTA V SX USING VIM
Lost VIM configuration file(VIO) and completely forgot VIM IP address
VIM card
Share

VIM-2 and Network Limitations

I am working on a project where I need communication with about 25 Packages- (compressors), each having about 15 Tags (Read) and 05 Tags (Write- mostly ON/OFF and speed control) - over Modbus TCP/IP

I am using two Simplex VIM-2 Cards, with S Series (SX) controller-

Will VIM-2 (02 Simplex Cards) be able to handle this much data? I checked on EIOCs, but those are like 4 times the price of VIMs- ( which is very surprising but a different discussion).

Any suggestions?

We also have three serial cards in the same system - which are communicating to some other Modbus RTU Packages.

ENGRIMRANTAHIR

14 Replies

  • Ray Emerson
    The VIM and VIM2 both emulate 4 DeltaV Serial Interface Cards. You can check system capacities inside DeltaV Books Online. Also, the S-Series VIM product datasheet is available here: www.emerson.com/.../s-series-virtual-i-o-module-2-en-57730.pdf

    The VIM2 can communicate to UP TO 128 devices and accommodate UP TO 128 datasets in one card. You'll need to determine how many datasets are required for the per-package tag count, and determine the total number of datasets from there.

    Specifically, if your reads are all in one dataset, and your writes in another, you'll have 2 datasets per device, and 50 datasets total across those 25 packages. This is well within the capacity of a VIM2.

    Conversely, if you each read and write are separated datasets, you'll have 500 datasets total, in which case your installed hardware isn't sufficient.

    Cheers.
    Ray
  • ENGRIMRANTAHIR

    In reply to Ray Emerson:

    Thanks Ray.
    highly appreciate your response.
    My plan is to have one Dataset for Read and one for write- for each device- so I am sure the limitations are OK.
    Question about DST:
    for all the Tags I need to write through Modbus ( Motor start/Stop (Discrete) , Speed control (AO), do I need a DST license for each or would one DST per the Write Dataset for each device will work? - which will mean I would need only 25 additional DST licenses?
  • foxriver

    In reply to ENGRIMRANTAHIR:

    My experience with serial cards and VIMs would tell me to be cautious about how many datasets you will need. When you setup a dataset you have to tell it the data format. So unless all the reads (and writes) from the device are the same format you may end up using more than one read and one write to get the data in and out of DeltaV in the proper format.

    Dave
  • ENGRIMRANTAHIR

    In reply to foxriver:

    Thanks Dave. I think i may end up using about 5 datasets per compressor. which will still be well within overall system limit 0f 128+128 (i am using two simplex VIMs with one SX controller set). what do you suggest about the DST licenses for these tags. I know the Read ones won;t need any DST, as those will be Scada Points. but will the control/write Tags need DST for each? I am always a little confused about DST licensing model/pricing
  • István Orbán

    In reply to ENGRIMRANTAHIR:

    DeltaV 12 and later will use just one DST per serial device (unless you have more than 16 datasets in the device): www.emersonautomationexperts.com/.../
  • foxriver

    In reply to ENGRIMRANTAHIR:

    I am at version 12.3 and it is like Istvan says. Each Dataset (DST) is a one DST license. If you are reading registers it will use one AI DST for the entire Dataset. If you are writing registers it will use one AO DST for the dataset. Read coils will be one DI DST and written coils will be one DO DST per dataset. Hope this helps.

    Dave
  • Andre Dicaire

    In reply to István Orbán:

    There are a lot of factors to consider when setting up your communications. Some of these things are not fully documented and that can lead to some unexpected results.
    The VIM emulates Serial cards as noted above. The DeltaV Controller IO bus manages bus access to prevent one card from monopolizing the bus and preventing other cards from talking. So the volume of data from a serial card can take multiple bus scans in order to read all the data. In addition, the serial card often hand serial communication limitations on the Modbus RTU side, so the scanning of datasets was slower than it might be over Ethernet. The IO bus is ultimately going to limit throughput. So although the VIM can handle 128 datasets, the number of datasets passed per second is closer to 20 or 30 Datasets.

    This will vary based on the size of the datasets. Also, datasets are passed by exception, so if you have more datasets, but many have data that is not changing, these will not need to be sent, making room for other datasets to pass more frequently.

    As mentioned earlier, data type and direction can also be a source of additional datasets. Output datasets are sent when they are altered, and this only happens when a module executes and writes a new value to a register. So output datasets are often stable. The write can also be by register rather than the entire dataset. Output data sets can also be set for readback. This allows a mix of Output and Input registers in one dataset. A device could be integrated with a single Output dataset with readback, if all the data is in one contiguous block and the data map allows for all the data to be of one type, like Holding registers. This would reduce the licensing cost to 1 AO DST, but not typically applicable to a Device due to the data mapping available.

    So back to separate Output and Input data sets, each data set can be Boolean (DI/DO), 16 bit integer, 32 bit integer or Float. max of 100 registers per data set, or max of 50 of the 32 bit Integer or float. Some devices use command words and status words that are 16 bit integers, and these can be read in the same dataset as other integer data, such as speed or setpoint, via holding registers. Others require separate Boolean datasets for accessing the start/stop and or status bits.

    Since every device is different in its data layout, you have to balance data throughput with data licensing. More datasets means more licensing, but smaller efficient datasets mean better through put. If you need two registers than span a few registers, one data set works. If they span 50 or 100 registers, two data sets of one or two registers will be better than one dataset of 100 registers with it likely changing every scan.

    Next, you need to consider the scan time of the devices. No need to scan them faster than the IO subsystem can pass them. The scan time of devices is set at the Serial card port, and all device/datasets are scanned in order as fast as this can be completed. In Modbus TCP, the VIM configuration determines the Ethernet device scanning, but ultimately, the data is presented to deltaV as a Serial card at an IO address and data is passed to the controller under the IO bus rules. So, setting the devices to be scanned appropriately and for only the data required can help reduce overall bandwidth usage.

    Unfortunately, there is no formula to calculate how fast a given VIM Modbus configuration will take. Some estimates place the bandwidth at about 20 to 30 datasets per second. The fastest scan of the IO bus is 20 ms for M and S series controllers. If in each scan, the card can send one dataset, and each card is scanned 50 times per second. If there are more IO cards on the bus, the bus scan can become longer than 20 ms. With conventional IO, this is often seen at 35 to 50 ms. This will impact the number of scans per second and thus the number of data sets per second. Remember that the IO bus was designed for IO cards, where each card has a limited amount of important process data to send. The serial card is capable of so much more data, but it cannot disrupt normal IO data updates. So each card gets access to the IO bus for a limited time per scan. I'm not sure of this time, or the bus speed, but if the bus is 500Kbps, and the bus scan takes 50 ms for 50 cards, one could conclude that each card gets about 1 ms, and that means 500 bits per scan, give or take. Maybe it is a max of 2 ms, and many cards finish much quicker. Whatever the actual details are, the point is it takes multiple scans of the serial cards to get all datasets updated in the controller.

    So if you are integrating Drives and Motor Protection Relays, and you want better than 500 ms update times, you will be better served with small datasets, and keep the amount of data to a minimum. Use two small datasets rather than one big one.

    I would also recommend you span your devices across the four emulated cards. This gives you 4 times the bandwidth versus putting all the devices on one card. Since each card is limited to 32 datasets, this eventually happens. Or you can add devices to one card until you find the response is starting to lag. That would be your max devices per card and you can load up on the other slots to that point.

    The VIM now supports the ODVA Ethernet IP to DeviceNet card format. The difference is that a DeviceNet card communicates specific configured Signals to the controller, and not an entire data map, like a dataset. The Device licensing is one DST for the first 16 signals, which can be Booleans, bytes, integers, floats and in either direction (input/output). But if you need more than 16 signals, each additional signal requires a DST license. The VIM emulates 4 DeviceNet Cards, or 4 Serial cards, or any mix of the two in Simplex operation. Redundant Operation does not support the DeviceNet card.

    So with a limited number of signals configured, throughput of the DeviceNet cards would typically be better than Modbus datasets, unless you use smaller datasets. If you have simplex cards, the DeviceNet may be a better choice for throughput and license costs, if you have EthernetIP devices.

    The EIOC delivers much greater through put as it does not pass data over the Local Bus for IO cards. But for Drives and Protection Relays, these are often needed tightly integrated in the controllers, and the VIM provides a better architecture for interlocks and using Drives in closed loop control. Another reason these devices are better on the controller is sometimes the command signals are hardwired to IO, and the bus communications are used for diagnostic and other data. The EIOC does not have hard IO, splitting the Bus data and command signals across two devices. You end up with two modules for the same device, which complicates display data, or forces more peer to peer data exchange than one might want.

    V14 changes:
    In v14 the EIOC pricing has been adjusted to use Device Licenses so that the overall cost is scalable to the number of devices used.

    Also in v14, the PK controller is introduced and comes with an integrated Ethernet IO port and provides greater through put as it too bypasses the Local Bus for IO cards. The PK and EIOC are licensed similarly in v14, and offer Modbus TCP and Ethernet IP for device integration. The EIOC also offers the IEC61850 protocol for Sub station, and OPC UA.

    The EIOC also gets Integration tools for Rockwell PLC instructions to facilitate PLC integration. The EIOC supports the PRP (Parallel Redundant Protocol) in v14, which is common in the IEC61850 domain, but it can also be used with any other protocol along with RED Boxes or PRP enabled switches.

    So the way I see it, the EIOC is a solid integration node for standalone subsystems. The VIM provides drive and motor integration to the controllers, with the PK delivering this with a native interface. Note that you can add the VIM to the PK and get additional protocols on the same controller. Also, the PK interface is redundant, but most drives and motor relays have a simplex Ethernet connection. You can use the redundant networks as A and B buses by connecting and addressing devices on the primary (A) or Secondary(B) subnets.

    For V13 and earlier, the VIM is your interface for controllers, and continues for M and S series controllers in the future. The VIM will also see enhancements to better serve the M and S Series customers. Both these controller lines are fully supported with no time line to retire them. So the VIM will be here for a long time.

    OK, that's enough. Hope this was somewhat useful.

    Andre Dicaire

  • Ashiner

    In reply to Andre Dicaire:

    Hi Andre,
    There're so many great information in your reply, which I've put into my favorites.
    There's one thing I'm not sure that you mention VIM can be added to PK. Is this feature in PK's future plan?
  • ENGRIMRANTAHIR

    In reply to Andre Dicaire:

    Thank you so much Andre for such a detailed reply. Indeed, it's very helpful and much appreciated.
  • Andre Dicaire

    In reply to Ashiner:

    Ashiner, The PK controller supports the DeltaV LocalBus and all local IO cards. The VIM2 connects to this bus and therefore to the PK controller. The emulated cards of the VIM2 (Serial Card, DeviceNet and Profibus) cards are supported by the PK controller. So by being compatible with the local bus, the VIM2 is compatible with the PK controller. The VIM continues to see development and is the Ethernet Interface for all M and S series controllers, neither of which are being retired anytime soon.

    It's a good question, but at the root of it, the PK literature states that it supports all DeltaV IO, and by extension, that includes the VIM/VIM2.

    Andre Dicaire

  • Tyler Anderson

    In reply to Andre Dicaire:

    Does the VIM no longer need to be installed to the left of the controller? How does that requirement work with the PK?
  • Andre Dicaire

    In reply to Tyler Anderson:

    The VIM must be installed before the first IO carrier. It was always recommended to be to the left of the controller, as this makes it possible to add a VIM online. It could always be installed to the right, though that may not have been documented.

    The devil is in the detail, but basically, an IO card is selected by the controller when its carrier and Slot number are set high. The Slot number is the physical position of the card on the Carrier, and the Carrier select line is common to all the cards on that carrier. What happens is that each carrier shifts the Carrier select lines prior to its connection to the next carrier.

    The VIM/VIM2 emulate cards on the 8th carrier (cards 57 - 60 and 61 - 64). When the controller selects carrier 8, the VIM sees this directly on the carrier select line #8. If an IO carrier is between the controller and the VIM, the VIM would see line 8 be active when carrier 7 is selected, and things would not work well.

    So if you do plan to use a VIM with a PK, it has to be installed immediately to the right of the PK carrier, before the first IO carrier. You cannot add the VIM on line to a PK controller that also has local IO, as you have to insert the 2 wide and thus lose power to the IO cards.

    Andre Dicaire

  • ENGRIMRANTAHIR

    In reply to Andre Dicaire:

    Andre,
    I have a question about the EIOC cards vs VIM when it comes to integration with MCC/Drives/Switchgear. As you mentioned, VIM probably will be better choice due tomorrow that tight integration with the current controller rather than EIOCs.
    If we use EIOC, what are major Pros n Cons?
    With EtherNet/IP, the DST model remains the same as you detailed above? ( I assume it’s not like Device Net)?
    I have about 200 devices/drives in the electrical system on Ethernet /IP and about 50 relays on 61850.
    And if i use VIM, the licensing for EtherNet/IP and 61850 will differ?
  • Andre Dicaire

    In reply to ENGRIMRANTAHIR:

    Those are good questions. The EIOC supports 256 devices, with native Ethernet data landing directly into the processors IO map. The VIM supports 128 devices/Datasets with data passing through the localbus IO via emulated Serial cards. In your case, you have two protocols. The VIM does not support IEC 61850, but often those systems can be integrated via a concentrator that serves the IED data via MODBUS TCP. I would use the EIOC for this, and either the native IEC 61850 MMS communication, or MODBUS TCP via the concentrator. You will want the through put of the EIOC.

    For the 200 Ethernet/IP devices, you need to decide if you will be controlling over the network or using the bus for diagnostic data only. If you have hard IO for star/stop and status and such, you need Controller based modules. I'd lean toward adding VIMS to the controllers and integrating devices appropriately (i.e. not all 200 device to one vim/controller, which you cannot do anyway).

    Here's one way of looking at it. If you were to connect all your drives and MCC's to a PLC as a data concentrator, and then pass this data to DeltaV controllers with VIMs, I'd say skip the PLC and use the EIOC as your data concentrator. That PLC would not be redundant and would be a single point of failure for all devices. The EIOC could easily be redundant.

    The VIM is also a Data Concentrator, and if you were thinking of doing control over Ethernet, you want to evaluate availability and segmentation of devices. That's a whole other discussion. But the VIM brings devices directly to the controller, and gives you best closed loop response for VFD's and ease of configuration, and support. Why make it complicated.

    So you could put 200 devices on one EIOC, but even if it is redundant, what about the network and all that. If you use a VIM on each controller and integrate per controller, and setup A/B busses, you might get a better design, though it may cost more for all the VIM's. IF you are thinking of passing 100 devices via a VIM for control, throughput may not get you there, and you are limited to 128 Datasets, so you are likely looking at no more than 30 to 40 devices per VIM (via Modbus Serieal card emulation. ) DeviceNet card Emulation can deliver more devices with better IO throughput, based on using less than 16 signals per device. (if you emulate the DeviceNet card in the VIM, licensing is per the DeviceNet card)

    Pros and cons I can think of.

    The Pros of the EIOC:
    - device configuration is native to DeltaV Explorer, not VIMNet explorer configuration.
    - Data through put to IEOC modules is much higher.
    - EIOC has more CPU capacity for handling integration of devices
    - EIOC handles 256 devices, with greater capacity for quantity of data as well as throughput.
    - Ideally suited for integration of independent subsystems: PLC's, Analyzers, RTU's, Switchgear with Load Shedding, etc.
    - Redundant architecture (processor and Ethernet network)

    Cons of the EIOC:
    - Initial cost (v13 based license model)
    - No native IO to allow for single control module for MCC and VFD strategies with IO requirements.
    - Support for UCMM does not include PLC tags (v13)
    - Peer to Peer communication adds latency to control involving controller based modules with EIOC modules.
    - Complexity of having EIOC based communication module with Controller based control module.
    - Requires minimum v13 DeltaV (debatable if this is really a con, but for a v12 customer, certainly is)


    Pros for VIM:
    - locally integrated to the controller, supporting MCC's and VFD's coupled with DCS IO. One module for control and diagnostic data.
    - Supports multiple ODVA certified interface. (This can be a requirement in some customer specifications)
    - Compatible with all versions of DeltaV (does not require v13)
    - Emulates both Serial Card or DeviceNet card, (and also Profibus card with Profinet)

    Cons for VIM:
    - Requires separate configuration tool via VIMNet Explorer.
    - Has different capacity for number of devices based on simplex versus Redundant configuration
    - Redundancy of network requires redundant processors.
    - Data Throughput is related to number of Datasets passed via IO bus (estimate 20 full datasets per second)(and IO bus scan time)
    - Device Data map can force large data size for limited valued data actually required.
    - MODBUS serial mapping (not an issue if using DeviceNet card emulation)
    - Change to Modbus mapping in data set can disrupt device communication. (can limit ability for online changes)

    If I had my druthers, I'd like the EIOC over the VIM, if it was a controller with local IO. Oh wait, that's the PK controller available in v14. Doesn't help us yet if we are v13 though. But soon. (v14 was just released this month)

    My biggest concern with the EIOC for MCC and VFD's is the whole integration with native IO and control strategies, which creates a large peer to peer profile, and adds latency to the data. If you are using hardwired control signals, you need a control module in the controller. If you are not doing control, then you could create your diagnostic modules in the EIOC, set them to 5 second update rates, and reference key data back to the controller module for display in the Faceplate and Detail displays, keeping the Operator interface simple. This relegates the Ethernet communications to a diagnostic function, and you could treat that as an independent subsystem, which in my book suits the EIOC. But VFD's need an AI, and typically control Flow's, so that added latency will impact your VFD based flow control.

    The VIM lets you bring the diagnostic data directly to the Controller without having two modules and building peer to peer communications. For a Closed Loop Flow control on a VFD, that's the way to go. However, as I mentioned, the data through put for the VIM is limited by the IO bus, which by design, is serving IO card data, with expectations of a hundreds of Bytes, not thousands. ( A 32 channel DI has 4 bytes of data to send, a Dataset with a hundred 16 bit integers has 400 bytes to send. ) So the VIM does pose some challenges if we want to integrate a lot of devices. Each Dataset on the Serial card is defined as either input or Output, and with data types of Boolean, Integer or Floating Point. If the device has a well defined data structure using Command words and status words, you could use a single Output Dataset with Read back to integrate that device, and it might only require 30 or 40 registers. But if you have to map data from different locations, you need to define multiple data sets, which adds to the IO Licensing, but more importantly, can add to the data size.

    The VIM's ODVA driver lets you use the DeviceNet card rather than the Serial card. This changes the underlying communications as the DeviceNet card is configured with "signals", where you may read an IO structure from the device of 50 or 75 bytes, and from this data extract a dozen signals. Only the signals a passed over the IO bus to the controller, rather than the entire map. This can help performance of the data to the controller. But the license scheme is that of the DeviceNet card, and as of v12, that means one DST for the first 16 signals. then it is one DST per signal above this. The Serial Datasets require one DST, but can have up to 100 Integers (50 Floating Point), so if you were to need more than 16 signals from a device, the Modbus Serial emulation would get you more data for fewer licenses.

    If you plan to use VIM's, you should have a VIM on every controller that will be needing Ethernet Device integration. I would not use a VIM on a controller in the place of an EIOC. If this architecture works for you, use the EIOC. In v13 this would be more expensive, but you would likely want redundancy if you push all devices through one node.

    Now speaking of redundancy, the VIM and EIOC in v13 support redundant networks, but most MCC's and VFD's do not. That is they recognize one Master address. But the EIOC and VIM support different IP subnets for redundancy. The redundancy is primarily for integration of PLC's with separate adapters. I believe it is possible with the EIOC to configure devices and connect them to either subnet, effectively creating two spate device busses. Similarly for the VIM. Some systems use IP Swapping of the Master to allow the Master interface to be redundant, but devices only see one address.

    Emerson has enabled PRP (Parallel Redundancy Protocol) on the EIOC in v14, which allows PRP devices to have true redundant communication, and for simplex connected devices, RED boxes or switches can be used to connect these to both busses. This was primarily done for the IEC 61850 interface where PRP is the preferred method.

    So if you have v12 or earlier, the VIM is the only option. Simple, I guess.

    In v13, the EIOC gives you an option, well suited for PLC's with MODBUS TCP or EthernetIP, and IEC 61850. But for MCC and VFD's native integration to the Controllers is desirable, I'd go with a VIM on each controller. I would not use the VIM on a single controller instead of an EIOC.

    I think Emerson is almost there in v14, with the change in licensing on the EIOC and the introduction of the PK controller with native Ethernet integration. The EIOC is now licensed by actual number of devices rather than its potential max, and the PRP protocol can greatly enhance network availability. The PK gives us the same Integration as the EIOC directly in the controller, addressing any through put issues and provides native configuration in DeltaV, (but PK does not have PRP).

    Emerson is also working to enhance the VIM to provide better performance on command signals on integrated MCC's and VFD's. This is to better serve the existing installed base with M or S series controllers. Note that the VIM has served customers well over the past decade or so for Ethernet Integration, and will continue to do so.

    For new green field systems, I recommend the PK and EIOC. It becomes easy to integrate 3rd party systems in the right location. Overall this simplifies the DeltaV system architecture, and at the controller level, there are no additional components for Ethernet integration, just the licensing of what you need. The EIOC is a solid choice for integrating subsystems, and with OPC UA as a protocol, a much better choice than an Application station for certain data sources.

    I might also use a VIM with a PK controller in situations where I had both Ethernet IP and MODBUS TCP requirements. It's a matter of getting data to the right location for control versus integration to the Operator Interface.

    Hope this was useful.

    Andre Dicaire

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.