This technical note is a brief description of the EtherNet/IP protocol support offered by the DeltaV Virtual IO Module.
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 paper does not discuss other CIP Class (0, 2, or 4 through 6) connections.
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 within a predefined number of RPI intervals. This type of communications is also referred to as a producer/consumer model. The sequence of this connection is:
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 triggering of fail-recover operations.
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:
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 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).
The VIM supports EtherNet/IP with two firmware versions 3.x and 4.x. The 3.x is a Class1 adapter (server device), and an embedded DF1 client (with redundancy support). The 4.x 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 controller.
|3.x Firmware||4.x Firmware|
|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)|
MYNAH Technologies LLC
390 South Woods Mill Road, Suite 100
Chesterfield, MO 63017 USA
© MYNAH Technologies 2012 - 2020. All rights reserved.
Designs are marks of MYNAH Technologies, Emerson Process Management, DeltaV, and the DeltaV design are marks of one of the Emerson Process Management of companies. All other marks are property of their respective owners. The contents of this publication are presented for informational purposes only, and while every effort has been made to ensure their accuracy, they are not to be construed as warrantees or guarantees, expressed or implied, regarding the products or services described herein or their use or applicability. All sales are governed by our terms and conditions, which are available on request. We reserve the right to modify or improve the design or specification of such products at any time without notice.
While this information is presented in good faith and believed to be accurate, Mynah Technologies does not guarantee satisfactory results from reliance upon such information. Nothing contained herein is to be construed as a warranty or guarantee, express or implied, regarding the performance, merchantability, fitness or any other matter with respect to the products, nor as a recommendation to use any product or process in conflict with any patent. Mynah Technologies reserves the right, without notice, to alter or improve the designs or specifications of the products described herein.