Knowledge Base /
Technical Notes
Ethernet/IP Support for the DeltaV Virtual IO Module
By Geoff Nash on 01.22.10
Product: DeltaV Virtual IO Module

The technical note describes the messaging supported by the Ethernet/IP Drivers for the DeltaV Virtual IO Module.

Ethernet/IP Overview

Most Ethernet/IP devices support one or more of three communication types, Class1, Class3, and UCMM. Each message type has benefits and handicaps; the selection of a type of messaging is based on those supported by both devices and the use of the connection. This article does not discuss other CIP Class (0, 2, or 4 through 6) connections. For more information on the capabilities of Ethernet/IP, please refer to the Open DeviceNet Vendors Association.

Class1 Messaging

Class1 also know as implicit or I/O messaging uses UDP messages to hold the data transferred between two devices. The Class1 connection is opened by a scanner (or client) device, the connection is to an assembly instance (or connection point) in the adapter device’s assembly object. First a TCP session is created (if one is not already present), then the actual Class1 connection definition is transferred and opened over the TCP connection, and finally the I/O messages consisting of just a connection identifier and data are sent via UDP. Each side of the conversation sends its messages independently of the other, and monitors for the receipt of messages. Messages are sent at a specified interval (RPI or request packet interval in the connection definition), although messages may be triggered faster with change of state definition or other criteria. Connection failure is triggered by the failure to receive a message predefined number of RPI intervals. This type of communications is also referred to as a producer/consumer model. The sequence of this connection is:

  1. Ping adapter device if necessary.
  2. Open TCP session to adapter device if necessary (only one session required for each device pair).
  3. Send NULL forward open to remote device (optional for some devices).
  4. Send a forward open containing the definition for the Class1 connection.
  5. Register multicast address messaging (if multicasting is used), two registrations occur, followed by re-registering as interval specified in network IGMP configuration.
  6. Send first message.
  7. Start listening for data messages, sending data message at defined interval (RPI)
  8. Repeat #7 until session is closed by scanner or adapter. The connection may be closed when no-longer needed, or if UDP messages are lost (timed out), or if the TCP session is lost.
  9. Send forward close (not all devices do this).
  10. Restart at 1 if and when necessary.

Class1 messages create a “connection” when first opened, this allows reserving buffers, but the number of connection points in a device are limited (128 for a Logix 5000). For listing to data from a device, multicasting is used to allow multiple devices to share a single connection. Class1 messages to and from a Logix controller do not support redundancy in Ethernet/IP. Class1 connections are extremely fast and have reproducible message intervals (RPI), however if the RPI is set to too fast a rate, the connection may be dropped if either the adapter or scanner cannot maintain the pace. Connections will fail in either (or both) sides based on failure of the underlying connection (timeout), allowing trigging of fail-recover operations.

UCMM (unconnected) Messaging

UCMM (unconnected messages) are often referred to as explicit (or unconnected explicit) messages. These TCP messages contain the definition of the specific object in a device and the action (service) to carry out as well as the data. The messages are a master/slave type of message sent by a client (master) and require a response from the slave (server), (which may or may not include data. These messages are TCP messages sent over the session initially created by the client device (a session will be created if one is not already present between the devices). All UCMM messages are sent over the same TCP session between the devices. The forward open (and close) messages for a Class1 or class3 connection are UCMM messages. The sequence for a UCMM is:

  1. Ping adapter device if necessary.
  2. Open TCP session to adapter device if necessary (only one session required for each device pair).
  3. Send UCMM message open to remote device.
  4. Wait for response; fail if none received in specified timeout period.
  5. For more messages to the same device, go to #3
  6. Restart at 1 if and when necessary.

UCMM messages require a response for each send and are therefore slower than the Class1 messages. Also each message requires an output buffer in the sending device and an input buffer in the receiving. These buffers (especially the receive buffers) are limited and used by other devices. Messaging must account for the limited buffers. UCMM messages may be sent to redundant devices, and for a device switch-over, a single message may or may not be lost; however, the “connection” should remain open if there are retries enabled for the message. The receiving (slave) device does not automatically fail an object on loss of a message (or messages), but must be programmed to fail with a watch-dog timer if necessary.

Class3 Messaging

Class3 messages are a combination of Class1 and UCMM definitions; they are “connected” explicit messages. The scanner starts a connection to the adapter using the same procedure as for Class1, but specifying the router object in the device rather than then assembly (1756-DHRIO Class3 uses a DF1 object). The data is sent over the TCP connection, and requires a send/response sequence. The data in the TCP packet contains the UCMM message. The receiving device processes any message with new data and ignores packets that have the same data. One of the fields is a “sequence” number that is changed by the sending device when a new “message” is triggered. The Class3 is a “connected” explicit message, versus the UCMM “unconnected” explicit message. The sequence is the same as for Class1 messages, however some scanner devices will terminate the connection following each message, and re-start when a new message is required. This is used to conserve “connections” which are often limited in servers (and adapters). Devices may also send multiple different UCMM messages to different objects using the same Class3 connection. Also for these connections,the RPI for the connection is usually set to a long interval and the messages are triggered by exception (data change or timing in the device).

DeltaV Virtual IO Module Support

The VIM supports Ethernet/IP with two firmware versions. For the VIM (Mynah grey box),  these are v3.x and v4.x. The 3.x (driver model IOD-4102) is a Class1 adapter (server device), and an embedded DF1 client (with redundancy support). The 4.x (driver model IOD-4104) version supports Class1 scanner and adapter connections and generic UCMM messaging as well as embedded DF1 messages (and Class3 embedded DF1 messages to the Rockwell serial DF1 bridge module (1750-DHRIO)). The 4.x version does not currently support redundancy with DF1 messaging to Logix controllers.

For the new VIM2 (Emerson box), the firmware is v5.x and driver model is IOD-4112. Firmware v6.x driver model is IOD-4114. These firmware versions are functionally identical to v3.x and v4.x, respectively.

Firmware - (3.x) IOD-4102, (5.x) IOD-4112
Firmware - (4.x) IOD-4104, (6.x) IOD-4114
Embedded DF1 messaging (UCMM)
Embedded DF1 messaging (UCMM)
Embedded DF1 messaging (Class3 to 1756-DHRIO)
Redundancy for DF1 messaging
Class1 Adapter (Generic ENBT server), single dataset per connection, output w/read-back
Class1 Adapter (Generic ENBT server), up to 5 datasets per connection, may have separate input and output sections that match Logix Controller ENBT definition.
Class1 Scanner (Generic client), mapped IO (data type and data direction) with to up to 5 datasets. Initializes connection to any Class1 enabled adapter device.
Generic UCMM with mapped IO, continuous or triggered messaging.
Message routing (CIP paths)