The purpose of this Application Note is to guide one through the necessary steps to sync data between two Generic Ethernet IP (IOD-4104) Virtual IO Modules (VIMs).
Data will be transfered between each VIM via Class 1 messaging. The process described below allows data to be transmitted between two DeltaV systems. Using the VIMs to commnicate between DeltaV systems decentralizes data concentration thereby eliminating the need for an additional data concentrator device.
The goal of this example configuration is to establish a Class 1 Ethernet IP connection between two Generic Ethernet IP VIMs and read 100 16-bit integers from one DeltaV system. The configuration in this article should be used as a starting point. More complex configurations can later be created based on the example below.
MYNAH Technologies recommends using Modbus TCP VIMs, in a Master/Slave configuration, rather than Generic Ethernet IP VIMs for passing data between DeltaV Databases.
As shown in the diagram above, both VIMs will need to exist on the same network to communicate. A computer with VIMNet Explorer installed will need to have access to the VIM network in order to configure the VIMs. One or multiple VIMNet Explorer configuration files may be used to configure both VIMs. Alternatively, VIMNet Explorer may be installed on either DeltaV Systems as long as the computer has a network connection to the VIMs. However, it is recommended to separate VIMNet Explorer from the DeltaV systems since it is not Emerson Proprietary software.
The terms "Client" and "Scanner" are interchangeable for this application, as well as are "Server" and "Adapter." Those familiar with Modbus and DeltaV may be more familiar with the Client and Server terminology. Those who are familiar with RSLogix and Rockwell products may be more familiar with the Scanner and Adaptor terminology. This article will use the terms Client and Server.
In Class 1 communications, the Client is the device that opens or “originates” the connection to the Server or “target” (sometimes the Client is referred to as the "Originator" and the Server is referred to as the "Target." The Client also determines the Requested Packet Interval (RPI). The terms Client and Server are only used to describe the role of the device at the connection level. These terms do not indicate the direction of the data. Conversely, the Modbus "Master/Slave" terminology implies a single Master is controlling the data direction, thus it is inaccurate for describing Class 1 communication relationships.
There are devices that act only as Class 1 Clients (ControlLogix), and there are devices that act only as Class 1 Servers (PowerFlex Drives, Ethernet IP VIMs). The Generic Ethernet IP VIM can act as a Class 1 Client or Server. The role that the VIM plays is determined by the Connection Definition settings. The VIM can be configured to act as a Class 1 Client for one connection and as a Server for another. When communicating to a ControlLogix or a PowerFlex Drive, the VIM will only play one role. With VIM-to-VIM communication, the role each VIM plays is open and determined by the user, but each connection must have a Client and a Server.
The naming convention in the following screenshots is only used to differentiate between the two configurations. The term, “CLIENT-VIM” is used to establish that VIM as the Client; likewise for the term, “SERVER-VIM."
The first step is to create a new Controller and IO VIM in VIMNet Explorer with the type Generic Ethernet IP 4.x. This VIM will act as the Class 1 Client in this example. Next, create a device instance for the second VIM which will be the Class 1 Server.
Secondly, right-click Ethernet IP Connection Library and select "Add Connection Definition" and the following window in Figure 3 will open. This Connection Definition will be used to define how the Class 1 Client VIM will connect and communicate to the Class 1 Server VIM.
Click the Msg Parameters button (Figure 3) and configure the settings shown in Figure 4:
As explained earlier, the Class 1 client is the Originator and the Server is the Target. These settings define the Client VIM’s outputs. The Target -> Originator settings are used to define the Client’s inputs.
Each Class 1 Server has a specific Connection Point or Assembly Instance for the inputs and outputs. The Connection Points must be defined in the Client Connection Definition for Class 1 communications to function. Generic VIMs do not have hard-coded Connection Points so the numbers are arbitrary for Generic-to-Generic VIM communications. A Connection Point must be chosen and these same numbers will be used later for the Server configuration.
The Priority Setting refers to the priority of the output/input messages. The default Class 1 outputs and inputs are scheduled.
Type refers to how the data is sent across the network. For instance, if Point to Point is configured for the Client’s outputs, it means the Client will only send the data to the Server. When Multicast is selected, the outputs are sent to a Multicast domain. Usually this is used for Allen Bradley products which require Point to Point for their inputs but send outputs to the Multicast domain. Point to Point is the most efficient transmission type for this application.
In this case this dataset will be used for reading data from the Server so the Data Size for the Outputs will be 0. (A Connection Point must be configured for both the outputs and inputs even if they aren’t actually used).
Notice that a Data Size of 200 was selected for the Target -> Originator Settings. The Data Size is calculated in Bytes. In this example the Client is going to read 100 16-bit unsigned Integers which translates to 200 Bytes.
The Run/Idle Header is an option for communication with Allen Bradley devices which send Padded Headers. The first 4 bytes are typically used for status information. Checking run/idle header instructs the VIM to not include this status information in the dataset. The Generic Class 1 Server has the ability to send or not send this status header. The key is to be consistent with how the Server will behave. If the Server includes the header then the run/idle header needs to be checked. In this example, the Server will be configured to exclude the status header in the dataset so the run/idle header check box should be unchecked.
The RPI (Requested Packet Interval) determines when the outputs will be updated in milliseconds. This value can be increased or decreased depending on the application. We typically recommend an RPI of 750.
Inhibition is not used for this application.
Connection Settings: Use the default settings under the Connection section for Generic-to-Generic VIM communications.
Once the Message Parameters are configured, the Connection Definition Window should look like the following (Figure 5):
The Ethernet IP Buffer (EtipBuffer) Settings are automatically changed according to the Msg Parameters and do not need to be edited. The Defined shows how many bytes are ready to be utilized for the dataset. The Configured show how many bytes have already been used.
The Base DataSet and Extended Dataset Settings are not configured automatically by the Message Parameters and must be set manually. A single Connection Definition can be used to create multiple datasets that are not limited to a single direction or type. If only one dataset will be used, then the type and data direction will be configured under the Base Dataset. If a single Connection Definition is used to create multiple datasets, then the Extended Dataset Definitions section would be used to define the other datasets.
In this example, the Client will read 16-bit unsigned integers. The Base Dataset Type can be left unchanged, but Output with Readback (default) needs to be set to Input. This example will only use one dataset with one type and direction so the Extended Dataset Definitions section will not be used.
(Using multiple datasets per connection definition or multiple directions per dataset can get confusing quickly so it is not recommended for Generic-to-Generic VIM communications).
The next step is to add the Read Dataset to the Ethernet IP Input Buffer Definition (Adapter to VIM) section.
Click "Add" and configure the following settings (Figure 6).
The finished Connection Definition should look like this:
The name can be specified here or a default name will be created when clicking "OK." The default naming convention is Class1_OT[output connection pt]-TO[input connection pt].
Next, add the connection to the Server VIM Device in VIMNet Explorer by right-clicking it and selecting "Add Connection." Select the Connection from the Ethernet Library Definition list and click "OK."
The resulting configuration is as follows:
Clicking on the Dataset in VIMNet Explorer shows EXACTLY what to configure in DeltaV for the corresponding dataset, and it is clearly labeled by each tab.
The first step is to add the new Controller and Server VIM. Add a new device under the port for the Client-VIM and specify the IP Address of the Client.
Next, create a new Connection Definition by right-clicking the Ethernet IP Connection Library and selecting "Add Connection Definition." Since this VIM will act as a Class 1 Server, the Message Type will actually be Class1 ENBT as shown in Figure 10. The ENBT name comes from the Allen Bradley ControlLogix ENBT which is actually a Class 1 Client. Checking ENBT allows the Generic VIM to communicate to the ENBT in the way the Standard Ethernet IP VIM does. In this case, the Class 1 Client will be the other Generic Ethernet VIM instead of the ControlLogix ENBT card but the Class 1 Server VIM will behave the same.
Click Msg Parameters and configure the following:
The Input Connection Point/Assembly Instance is used here. There is no need to configure the Output Connection Point. The Maximum RPI setting is not really important and the Exclude Input Status Bytes is another configuration setting regarding Pad Words which aren’t being used in this configuration.
The next step is to define how many bytes will be used for the Server Dataset. In this case, the dataset is generated automatically by the defined Ethernet IP Buffer. In this example the Client is reading 200 bytes from the Server so the Server will be outputting 200 bytes. The final Connection Definition should look like Figure 12.
Next, add the connection to the Client-VIM Device by right-clicking the device and selecting "Add Connection." Select the Connection Definition from the list and select "OK."
If you have any questions regarding this technical note, please contact MYNAH support by creating a support ticket at www.mynah.com.
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.