Knowledge Base /
Integration Guides
DeltaV Integration of DeviceNet Modules Using The AB 1788-EN2DN Ethernet/IP Gateway
By Geoff Nash
Product: DeltaV Virtual IO Module - VIM2

This technical note describes the recommended settings for integrating DeviceNet devices using the AB 1788-EN2DN Ethernet/IP gateway and the Generic Device Ethernet/IP driver for the Virtual IO Module.

Introduction

The 1788-EN2DN is a linking device to allow access of DeviceNet devices via Ethernet/IP. This allows explicit and Class1 I/O data to be transferred. The 1788-EN2DN contains 496 bytes of input data and 492 bytes of output data that can be configured using RSNetWorx for DeviceNet, as well as 128 bytes of status data for the module. Two Ethernet/IP connections to the VIM are required for each 1788-EN2DN module: one for data and one for DeviceNet status information. Since these buffers may contain a mix of data types and unused areas, the connection to DeltaV is “mapped” to allow the use several DeltaV datasets with different data types that hold values from different portions of the data buffers for the connection, dependent on the type of data in the buffer. The mapped connections are used to transfer complex data structures between the two systems. While datasets in DeltaV may be assigned as output with read-back, any individual register will be either input or output. The two definition files (“vdf” files) supplied by Mynah may be used as a starting point in configuring the connections. These will be modified depending on the definition configured in the 1788-EN2DN module with RSNetWorx for DeviceNet.

VIM Configuration

This section provides information for configuring 1788-EN2DN connections to the VIM. It assumes the user is familiar with configuring the VIM using the VimNet Explore Utility. This device requires two Class1 connections: one for IO data and one for status information.

Open the VimNet Explorer. If the appropriate configuration is not already loaded, create a configuration containing the VIM and 1788-EN2DN Device. Right-click on the “EthernetIP Connection Library” leaf in the navigational panel on the left of the display. Select "Add Connection Definition" or "Import Connection Definition" to load a default vdf file.

The "Add Connection Definition" will automatically open the connection definition edit dialog. If importing, you must select the definition for modification (right click on the definition and select "Properties"). This opens the “VIM_EtipBufferMapping.” Utility shown in Figure 2. This is the utility that allows the configuration of the connection between the VIM and the 1788-EN2DN. This figure shows the definition of the “1788-EN2DN_Data.vdf” (Class1 I/O) module we supply as a starting point. Please click here to download a zip file containing the VDF files.

The connection definition dialog is comprised of several areas. The upper left corner has the Library Name and Version. These are used to uniquely identify a connection definition. Below this is the Ethernet/IP buffer definition. This includes the radio buttons to specify the message type (must be class1 for this device), and the message buffer sizes. Below this are the base dataset definition (one dataset is required for each connection) and a grid containing the remaining datasets for the connection.

The right side of the dialog has three grids; the top allows the mapping of the input buffer into the specified datasets. The middle grid allows the mapping of the output buffer, and the bottom grid would allow the mapping of configuration data if needed. This is not used for the 1788-EN2DN module.

If you wish, you may enter a new name in the "Library Name"field. Then edit the "Etip Buffer" sections below if necessary.

The "EtipBuffer" section of the dialog allows modification of the message buffers used for data communication. Make sure the message type radio button (Class1) is checked. The ENBT field is unchecked, and Cfg1 and Cfg2 buffer sizes are left at “0”. For the “Input” and “Output” fields, show the selected number of bytes that will be included in the communications message buffers.

The Input field specifies the size of the 1788-EN2DN to VIM (target to originator or TO) buffer, which is used to transfer the assembly data in the 1788-EN2DN to the VIM. The default is 500 bytes. This may be adjusted from 4 to 500, depending on the number of device net devices and the input data configured for those devices. Leaving this at 500 bytes will have little impact on the performance of the VIM and is recommended.

The Output field specifies the number of bytes of data transmitted from the VIM to the 1788-EN2DN (Originator to target or OT). The default for this is 496. Although it may be adjusted from 4 to 496 depending on the configured devices, it is recommended to leave it at this value. Leave the Cfg1 and Cfg2 buffers at 0.

You may examine the Class1 connection parameters; select the "MsgParameters" button to open the "SpecialData" utility. This utility allows you to view or modify the necessary parameters to configure the actual Ethernet/IP Class1 connection. For the 1788-EN2DN _Data, most of these are fixed and should not be changed.

The RPI (requested packet interval) should be adjusted to optimize the VIM operation. Set the RPI to the required interval. This is the expected time for the 1788-EN2DN (TO) and VIM (OT) to send data messages.

The OT (or Originator (VIM) to Target (1788-EN2DN)) is 150. The TO (or Target to Originator) connection point is 100. Both OT and TO connections should be to “Scheduled” and Inhibition “Default." The OT connection should be “Point to Point” while TO should be “MultiCast."

The OT connection should have the "Run/Idle Header" checkbox checked, and the TO should not. The Data size for both of these was set using the "VIM_EtipBufferMapping" Utility.

Finally, the overall connection parameters are the “Use Slot Addressing” (unchecked), Transport Trigger, “Cyclic," and Timeout Multiplier (4 times the RPI). Configuration Connection should be 1.

If any value has been changed, the last step in the SpecialData words is to select "OK" to save these parameters into the current connection definition in the "VIM_EtipBufferMapping" Utility. To exit without modifying the definition, select "Cancel."

For the 1788-EN2DN, the base dataset and four extension datasets are configured as 32-bit unsigned integers (Figure 6). This may be changed depending on the data transferred from the configured DeviceNet devices. All datasets are output with read-back. This allows sufficient space for configuring mapping elements for all 500 bytes of input and 496 bytes of output data. The first 8 bytes (2 registers) is status and control information; the remaining bytes is I/O data formatted in the 1788-EN2CN module with the RSNetWorx for DeviceNet utility.

We have provided mapping of all data buffer bytes into the configured datasets. These may be modified to improve operational efficiency (Figure 7). You may remove any mapping elements that are not necessary for the configured DeviceNet devices. While this is not necessary, transfer of data from the buffer into DeltaV datasets does require processor time on the VIM and will affect performance even if no devices use the transferred data.

In the default configuration, each dataset is divided into two sections to allow the both input and output data to be transferred. 100 bytes of input data is followed by 100 bytes of output data (96 bytes following the 8 status and control bytes in the first dataset). If less than the complete IO buffer needs to be transferred to DeltaV, then remove the last mapping elements (back to the last configure byte), and remove any unused datasets. If part of a mapping element is required, it may be edited by selecting the element then clicking the "Edit" button, or double clicking on the element row.

If more input than output bytes (or vice-versa) are required, redirect the mapping elements as required to fill the unused registers in the last dataset or datasets.

The first 4 bytes of input buffer are status bytes sent by the 1788-EN2DN module. These will always be present, the remaining 124 UINT32 values represent the Input data as configured in the unit and the number required will depend on the DeviceNet configuration.

The first element in the output mapping element table is the command byte register. This is always present in the output buffer. The remaining elements as for the Input table may be adjusted to reflect the actual configuration of the 1788-EN2DN module.

To modify or create a mapping element, select the "Edit" or "Add" button next to the buffer (i.e., Ethernet IP Input Buffer Definition--Adapter to VIM). This will open the "Etip Input Buffer Map" dialog (Figure 8). In this dialog you may select the dataset, offset into the dataset and the number of bytes in the buffer to map. The location in the I/O buffer is determined by the order in this grid (i.e., shown in the "EtIP Buffer"field). You will normally accept the next dataset offset (increment as new rows are added), the bytes field depends on the DeviceNet configuration in the 1788-EN2DN module. Double click (or select "Edit" button) to edit an existing row in the buffer definition. Note that if this is an “unmapped” element (not used in DeltaV), the "Unmapped Bytes" checkbox is selected, and the row does not show a dataset or offset. These bytes in the IO buffer will be ignored.

Selecting the "Fields" button will open a dialog (Ethernet/IP Buffer Fields) shown in Figure 9 that will allow you to enter a series of field definitions. Each field may specify a data definition assigned to the assembly table(s) for the connection. These have no effect on the communications between the Q-Impact and DeltaV; however, the field definitions allow you to document the format of the transfer buffer and will show the specific DeltaV dataset registers associated with the specified fields in VimNet Explorer.

Each field is added by selecting the "Add" button, then filling out the parameters (including the data type of the field), the starting byte in the field, and bit (if a bit field). Also, the size (elements) may be set if the field is an array of the data type.

Each element in the IO buffer gird points to a specific range of bytes in the buffer and maps these to the specific dataset registers for that type (or specifies them as unmapped).

Finally, you select "OK" on all of the dialog boxes to accept the configured values or "Cancel" to leave them unmodified. You are returned to the VimNet Explorer “Ethernet IP Connection Library” with the new definition added.

To add this to the VIM configuration, select the Node, the specific VIM, card, port and device for the connection, then right click on the device and select "Add Connection." In the dialog box, add a description and select the specific connection definition from the "Ethernet Device Definition" combo box. The connection is added to the list and the next available dataset(s) in DeltaV are assigned. You can open this connection by selecting the plus (+) in front of it, and examine the definition of each assigned dataset here. When configuring the actual DeltaV datasets (DeltaV Explorer), you may use these definitions as a reference.

This process is repeated for the status connection to the 1788-EN2DN module. First load the 1788-EN2DN_Stat.vdf module into the VIMNetExplorer Connection library (configuration dialogs shown in Figure 10 and 11)

You will leave the connection parameters as defined (except for RPI for each direction), but you may map the I/O buffer to the dataset(s) in the status connection. Again, select "OK" on all of the dialog boxes to accept the configured values or "Cancel" to leave them unmodified. You are returned to the VimNet Explorer "Ethernet IP Connection Library"with the new definition added. As for the data connection, add this to the VIM configuration

DeltaV Configuration

The actual connection between the 1788-EN2DN and DeltaV is configured in VimNet Explorer. The DeltaV dataset(s) assigned in DeltaV Explorer may be on any card (57-60) / port (1-2) and device, but they must match the definition as specified in VimNet Explorer. Click on one of the datasets, all DeltaV parameters for the dataset are shown in the detail window.

One or more datasets are assigned to a connection as necessary. There is always at least one dataset to define a connection; the remaining datasets for the connection (if required) must immediately follow the first.

To start, use DeltaV Explorer to select the device. Right-click, and select "New Dataset" to open the Dataset properties dialog. In the General tab (Figure 13), select the data direction of the connection data for this dataset. Since these are mapped datasets, if the dataset is to include output assembly data, this will be “Output.” If it is to include input data, enter “Input.” If both, enter “Output” and check the “Output Read-back” box. Refer to the VimNet Explorer definition of the dataset for actual requirements. Output mode should be 0, as Class1 messaging transmits all IO data in each message.

The DeltaV tab (Figure 14) of the dataset property box is used to select the data type of the data that will be presented. This should be appropriate for the data that will be accessed in the 1788-EN2DN. If the data in the assembly table is floating point, only a floating point dataset in DeltaV is appropriate as noted above. Mapping of datasets in the connection allows this to be assigned separately from integer and bit registers.

On the PLC tab (Figure 15), the “Device data type” may be specified, but is not required. If specified, the first dataset associated with the connection is specified with a device data type of 39 (mapped EthernetIP Class1 client) on the PLC tab. The remaining datasets are assigned 36 (EthernetIP extension data). In addition, the number of values on this tab will determine the size of the connection data read/written from this dataset. The number of registers in the associated datasets mapping elements determines the total data in both directions, by the data direction, type, and size in each dataset.

All words on the special data tab (Figure should be 0 (any values here are ignored).

Configured Fields [1]

Data Connection Input Status Register values

Bit

Field Name (in vdf file)

Description

0

RunStat

EN2DN is in Run mode (Cleared if in Idle mode)

1

FaultStat

EN2DN is faulted

2

DisableNetwork

DeviceNet network interface is disabled

3

DevcieFailure

Communications has failed with at least 1 DeviceNet slave

4

Autoverify

At least 1 DeviceNet slave is incorrect device type

5

ComFailure

DeviceNet network interface bus is off

6

DupNodeFail

Duplicate MAC ID error

7

DnetPowerDetect

No DeviceNet Power

8-31

N/A

Not used

Data Connection Output Command Register values

Bit

Field Name (in vdf file)

Description

0

Run

Set (1) sets the linking device to Run mode (RunStat input is set, Idle Mode Status bit is reset), reset (0) sets the linking device to Idle mode.

1

Fault

Fault. Sets a fault condition in the linking device

2

DisableNetwork

Disable DeviceNet network

3

N/A

Not used

4

Reset

Reset the linking device

5-31

N/A

Not used



[1] Modified from Tables 4, 6, and 7 in Rockwell publication 1788-in055_-en.p.pdf; “EtherNet/IP-to-DeviceNet Linking Device." For further information on the data presented in these tables, see the Rockwell documentation.

Status Connection Input Registers

Byte Offset

Size in Bytes

Data Type

Name

Description

0

4

UDINT

Scan Counter

The number of DeviceNet I/O scans that have taken place since the linking device was powered up

4

8

64-bit Bitstring

Device Failure (Faulted Node Table)

Indicates which DeviceNet slaves are faulted. Each bit represents the status of the slave at the corresponding MAC ID.

12

8

64-bit Bitstring

Auto Verify Failure (Error Table)

Indicates which DeviceNet slaves are the incorrect device type. Each bit represents the status of the slave at the corresponding MAC ID.

20

8

64-bit Bitstring

Device Idle (Idle Node Table)

Indicates which DeviceNet slaves are in Idle mode. Each bit represents the status of the slave at the corresponding MAC ID.

28

8

64-bit Bitstring

Active Node Table

Indicates which DeviceNet nodes are configured in the EN2DN’s scan list. Each bit represents the status of the slave at the corresponding MAC ID.

36

4

ASCII[4]

Status Display

Mimics a 4-character alpha-numeric display. If there are no faults, the display shows the linking device’s MAC ID and its Run/Idle status.

If there are faults, the display will scroll through the MAC IDs of the faulted nodes and display the error code associated with each.

40

1

USINT

Scanner Address (EN2DN MAC ID)

The DeviceNet MAC ID of the linking device

41

1

USINT

Scanner Status

The current status of the DeviceNet scanner

42

1

USINT

Scrolling Device Address (MAC ID)

The scrolling address and status fields scroll through the address and status of all DeviceNet slaves that are faulted. This scrolling includes the linking device scanner itself.

The scrolling fields change once a second.

43

43

1

USINT

Scrolling Status

44

20

USINT[20]

Reserved

64

64

USINT[64]

Device Status (Node Status Table)

The current status of each DeviceNet slave node. Each array element is the status of the node at the corresponding MAC ID.

If a node is not configured in the linking device scan list, the status value will be set to 0.

The linking device scanner status appears at the entry associated with the linking device MAC ID.

Timing Constraints

Accessing data via EthernetIP from DeltaV entails transmission through several interfaces; each interface may add some delay to transfer of messages. These interfaces are the DeltaV to VIM gateway, VIM to EN2DN module, and EN2DN to DeviceNet device.

The DeltaV to VIM has an update time for incoming data of from 10 to 30 ms per dataset on a card. The time for multiple datasets on the same card are additive, but not between cards. This is due to the method of updating the large data buffers of the serial card used. The DeltaV database polls card on each scan of the IO bus, if the card has a modified dataset, the card then responds that it has new data. The DeltaV database now polls for the specific dataset data. The more datasets that update in a scan, the more updates are required for DeltaV. Each card is polled separately, so spreading the I/O across multiple cards (if possible) will improve the response time for data. To minimize datasets, remove any mapping elements and datasets from the VIM library definition for parts of the buffer that contain no usable data. The communication buffer size may be left at the default, but the mapping elements to the unused section of buffer may be set to “unmapped” in the configuration utility. If this leaves any dataset unused, it may be removed from the configuration. Finally, the DeltaV modules run at a maximum rate of 100 ms. This means the total transfer time will be in increments of 100 ms, i.e., either 100 or 200 ms) for the response of a data change by DeltaV.

The VIM to EN2DN module is a Class1 connection. This means that the module is configured with an update time (RPI or requested packet interval) for both input and output data in the VIMNet configuration utility. Both modules send data at the interval specified, if either unit does not receive a message from its partner in the time (including a timeout period), then the connection is terminated. The VIM RPI this should be set to no less than 50 ms for both input and output sides of a connection. If multiple connections are installed on a VIM, then this should be increased, 100 to 400 ms are good values, although a small number of connections may be specified at a faster rate if necessary. If too many connections are set with too fast an RPI, some, or all, of the connections may periodically time-out. If this occurs, some of the connections will need to have a longer RPI setting. Changing the RPI of the connection will have significant effects on the communications between DeltaV and the DeviceNet device. Changing the size of the IO buffers will have little or no effect. These should be left as maximum values and set the mapping elements to the unused section of the buffer to “unmapped”. The following graph shows the update time (total loop from EN2DN to controller and back to EN2DN), toggling the enable command bit on the module, and watching for the enable status. The update time ranges from about 80 to 160 ms, with an average of 50 and a standard deviation of 18. Note the pattern as the VIM 50 ms scan cycle shifts with respect to the DeltaV 100 ms scan. The worst case is less than 200 ms.

The final interface is the EN2DN to DeviceNet device. This update interval is dependent on the data channel (DeviceNet) data rate and the module response time. This DeviceNet data rate may be 125, 250, or 500K, but all devices on the network must have the same rate. This test was run with the CommanderSE motor controller and a DeviceNet data rate of 125K. The response shown is the overall response from DeltaV to the module and the response. The test was to set the “Trip” bit in the module control word, when the response shows the module disabled, the “Reset” bit was sent. For this the EN2DN module was enabling, the CommanderSE was enable and set in Forward mode, but the Fieldbus control bit was not set. There are two update periods that were measurable to the field. The Trip (response controller disabled) responded, and reset response enabled. This alternated giving two intervals of 200 and 1300 ms.

The field response makes up the greatest time in this test, with the trip reset response requiring 1350 ms and the reset only about 250 ms. This response comprises the communications and module response time and therefore the field time will vary by module type, as well as by DeviceNet data rate and number of field modules.