Quantcast
Channel: MYNAH Technologies, LLC
Viewing all articles
Browse latest Browse all 401

DeltaV Integration with a CSI6500 Utilizing the Virtual IO Module

$
0
0

This integration guide describes the recommended settings for integrating the CSI6500 Modbus TCP/IP compliant A6824R interface cards to DeltaV utilizing the Emerson Virtual IO Module (VIM) with the MYNAH Modbus TCP/IP driver. The A6824 / A6824RCommunication module is a component of the CSI 6500 Protection machine monitoring system. This module performs cyclical polling of CSI 6500 Protection monitor data. The captured data are output via Modbus RTU or Modbus over TCP/IP.


Introduction


Resources

  1. CSI 6500 Machinery Health Monitor – Protection and Prediction in a Single Chassis
  2. MYNAH Online VIM Help Files

Hardware Requirements

  • DeltaV Virtual I/O Module 2 (VIM2) VE4026: M-Series or SE4026: S-Series
    MYNAH Technologies Modbus TCP/IP Master Driver (IOD-4111)
  • DeltaV Controller
  • (3) DeltaV 2-Wide
  • (3) DeltaV power supply
  • CSI 6500 Protection Monitoring System
  • (2) A6824R
  • Interface cable for connecting a PC to the RS232 configuration port on the A6824R

Software Requirements

  • DeltaV System Software (Release 10.3 or later) installed on a hardware-appropriate Windows workstation configured as a ProfessionalPlus Workstation for DeltaV (requires license)
  • DeltaV Explorer
  • DeltaV Diagnostics
  • DeltaV Control Studio
  • CSI 6500 Configuration Utility
  • VIMNet Explorer

Guide Assumptions

The user has an installed CSI 6500 Modbus TCP compliant Remote I/O System with appropriate I/O Modules connected to the system (A6824R) and is familiar with VIMNet Explorer, DeltaV, and the CSI 6500 configuration software.


Integration


Theory of Operation

The DeltaV VIM provides a native DeltaV I/O interface to the CSI 6500 A6824R communication module via an open plant Ethernet network and Modbus TCP (RTU TCP) protocol. DeltaV controllers can read and write signals to the A6824R residing on this Ethernet network. As such, the VIM exists as a Network Gateway between DeltaV controllers and the external CSI 6500 nodes. This connectivity is illustrated below:


A6824R Configuration

For operation of the communication module, a configuration must be created with the A6910 configuration software and then loaded into the module. The following portion of this manual assumes a configuration has been loaded into the module and briefly highlights strict parameters necessary for successful communications to DeltaV VIM cards. Additionally, the interface cable for connecting the PC to the RS 232 port on the A6824R is required for all configuration changes.

Please reference the OM_A6824_Communication_Module.pdf included with the product for additional setup information.

1. To start the configuration software, navigate to:

All Programs->Emerson Process Management->CSI 6500 Configuration->CSI 6500 Configuration

For the first start of the program, login with ID “first” and Password “user”.

2. The communication module is configured and edited under the “CSI Configuration” icon in the configuration tree.

Once configured and selected, parameters are entered / edited by selecting the “Configuration – Edit” menu item or clicking on the hammer-icon in the symbol bar. A menu with two tabs for the input of parameters will open. Please contact Emerson for specific information regarding the Administration and Configuration tabs.

3. A third Redundancy tab appears when connected to the A6824R module with firmware version of 1.05 or later.

The following steps must be complete for configuration and activation of redundancy mode:

a. Check the “Redundancy active” checkbox.
b. Enter the “wait time” parameter (minimum of 5 seconds). The Secondary Master will wait this amount of time before taking over communications when traffic on the 6 COM lines stop to the Primary Master.
c. Enter the corresponding bus addresses of the Primary Master and Secondary Master.
d. Enter the corresponding TCP/IP addresses of the Primary Master and the Secondary Master.
e. Click “Apply” and/or “OK”.
f. The configuration must be downloaded to both A6824R communication modules with the “Send configuration” command. Section 4 below describes the download procedure.

4. To download the configuration to the A6824R modules, the communications settings must be adjusted in the configuration software.

Open Options – Properties…

On the “Connecting” tab enter the COM “Port no.” being used on the PC. Select “Gateway 6824”. Accept the settings by clicking the “Apply” button, then click “OK” to close.

Transmit Parameters:
To activate the connection between computer and module use the “Connect” in menu “Connection” or by clicking the chain symbol.

Setup Connection
To load the configuration into the module, use the “Send” in menu “Configuration” or use the “Down Arrow” symbol.
Transmit Data

Receive Parameters:
To receive the parameter file form the module, use the “Receive” in menu “Configuration” or use the “Up Arrow” symbol.

Receive Data
To open the received configured use the “Edit” in menu “Configuration” or click the hammer symbol.
Edit Configuration

Edited data must be loaded again.

5. The Modbus TCP interface provides 100 main values, plus additional extended address information, as Input Registers for each monitor. The following Modbus TCP parameters can be entered from the “Options” selection on the menu.

Menu “Options” > “Set IP Address”Menu “Options” >“Set Address”
TCP/IP Number:
192.168.1.101
Unit: Modbus Slave address of the A6824R module
Subnet Mask:
255.255.248.0
Port: 502 (Standard port for Modbus over TCP)
Gateway Address:
192.168.1.1

DeltaV and VIMNet Configuration

1. Use the VIMNet Explorer utility to configure the VIM card.

Open VIMNet Explorer. Expand VIMNet and Physical Network until I/O Net is displayed, as in the image below. Right-click on I/O Net and select “New Controller”.

A prompt will appear asking for a controller name. The name of the controller used in this example is shown below.

Expand I/O Net until the new controller (labeled “NODE1” in this example) is displayed. Right-click on the controller and select “New IO VIM”.

A prompt will appear requesting specific configuration information about the new I/O VIM. For configuring the VIM to work with the EBIM node, enter a valid IP address on the device network and select the appropriate parameters based on the VIM type.

Expand the controller and the newly created I/O VIM, then expand C57 to show the two ports attached to Card 57. Right-click on P01 and select Add Device.

Set the IP Address to the IP Address of the A6824R modules. Click “Add” to define redundant IP addresses for the two A6824R modules. Redundancy with No Switching IP means the field device has two IP addresses, where the active IP address can be either of the IP addresses defined.

After the IP Address is selected, add a description and click OK.

A new device should now appear under the first port of Card 57. This device is the Modbus TCP CSI 6500. VIMNet Explorer simply configures the VIM to map a DeltaV Device Address to an IP address in the field.

Right-click on the VIM placeholder under the EBIM controller node and select Commission.

Select the VIM connected to the backplane containing the DeltaV controller and click OK.

Repeat for the redundant VIM.

A blue arrow will appear next the VIM placeholder after it has been successfully commissioned. The arrow indicates that an upload is required to the VIM due to the difference between the VIMNet Explorer configuration and the running configuration in the VIM. Right-click on the VIM placeholder and select Upload Configuration to VIM. After the upload is complete VIMNet should indicate a successful upload and the blue arrow should disappear.

VIMNet Explorer is now fully configured and the VIM can now map a DeltaV device to a field IP address.

2. Configuring a DeltaV Controller to Communicate to the CSI 6500

Launch DeltaV Explorer. Expand System Configuration, then expand Physical Network. Right-click on Control Network and select New->Controller.

Give the controller a name, then right-click the controller and select commission. Select the controller from the decommissioned nodes list. If the controller does not appear on the decommissioned nodes list, please investigate the DeltaV network.

When prompted Auto-sense the I/O cards. The I/O card may be auto-sensed because we have already configured in the VIM in the previous section. If the DeltaV is configured before VIMNet the cards will need to be manually added or auto-sense later.

Expand C57, then right-click on P01 and select Properties.

Check the Enable box for the port, then click OK.

All devices under a port share the same communications mode and timing values.

Mode
Master - all underlying devices in this port will be considered as external slaves to whom the VIM will connect.

Slave - the underlying datasets will be "servers" to which one or more external masters will connect. The VIM only listens for new connections in this mode.

Retry Count
This is the number of times a message will be transmitted, if there are errors, before the VIM gives up on a specific message. This number does not include the original message transmission. For example, setting this value to 5 could potentially result in a message being transmitted 6 times before the VIM gives up and moves on to the next message in the transmit buffer.

This retry count does not include any retry attempts due to underlying protocols, such as TCP. For example, TCP includes a sophisticated retry mechanism based on message round trip time. Retries at the TCP layer do not count against this retry count.

Message Timeout (ms)
This is the amount of time the VIM waits for a response (i.e., the command result) to a message before giving up on it and moving to the next message. This timeout is an application-layer message timeout, it is in addition to the built in TCP message timeout. This timeout value should be set high enough so that there is enough time for the field device to service the request and round-trip message transmission.

The total time the VIMVI may wait before reporting an error is:

Session Timeout = (Retry Count + 1) * Message Timeout

If the field device does not respond within the session timeout, the VIM will close the connection. The VIM will attempt to reconnect to the field device after waiting 15 seconds. The VIM will continue this behavior until it connects with the field device.

This message timeout does not include any timeouts set by the underlying protocols, such as TCP. For example, default TCP timeout mechanisms could wait multiple minutes before disconnecting. The VIM overrides this behavior with the session timeout in the above equation.

Transmit Delay (ms)
For all messages related to field devices on this port, the VIM will insert the specified amount of time between each message it transmits on the network. This is a tuning parameter for slower devices that do not have large message buffers for network messages. This parameter is especially useful for Ethernet-to-serial gateway devices.

Send Outputs on Startup
When this option is checked, the VIM will write all output values to the target field device after one of the following events occurs: Reboot, DeltaV card download, DeltaV controller download, or DeltaV controller power cycle. After this "first pass" the VIM will resume normal output operations (i.e., write outputs on state change).

When this option is unchecked, the VIM will only write output values on state change.

Next, right-click on P01 under C57 and select New Serial Device.

Ensure that the “Device Address” parameter is set to the same node address assigned to the device in VIMNet Explorer.

Right-click DEV01 under P01 and select New Dataset. A dataset will be created for each physical IO module in the CSI 6500 chassis.

The following instructions are for configuring each of the datasets:

  • FC 01 - Read Coil Status – Device data type = 0, Input
  • FC 02 - Read Input Status – Device data type = 1, Input
  • FC 03 - Read Holding Registers – Device data type = 3, Input
  • FC 04 - Read Input Registers – Device data type = 2, Input
  • FC 05 - Force Single Coil – Device data type = 0, Output type = 1
  • FC 06 - Preset Single Register – Device data type = 3, Output type = 1
  • FC 15 - Force Multiple Coils – Device data type = 0, Output type = 0
  • FC 16 - Preset Multiple Registers – Device data type = 3, Output type = 0

For more information on configuring a DeltaV dataset with Modbus TCP mappings, please consult the VIMNet Explorer Help Topics.

In this example, two modules are assigned to the DeltaV controller. The first landing module will read the input module channels, while the second module will write data to the output module channels. Landing modules should be created based on the standards of the DeltaV end-user.

Finally, right-click on the DeltaV controller and select Download; choose to download the whole controller.

DeltaV is now ready to communicate to the CSI 6500 in the field. The IO has now been fully migrated from the channels on the modules to the A6824R across the Ethernet network via Modbus TCP to the VIM card and presented to the DeltaV serial dataset channels.


Redundancy Mode

Redundant Field Device with Single Chassis
In this case the field device has a single chassis but uses two network interface cards for communications with the VIMs. Connect each network card to a separate isolated switch corresponding to the VIM. The IP address of these network cards can be consecutive, e.g. 192.168.1.101 and 192.168.1.102.

VIM A opens connections with both IP addresses 192.168.1.101 and 192.168.1.102. VIM B also opens connections with both IP addresses 192.168.1.101 and 192.168.1.102. The Active VIM communicates with the first IP address, while continuing to ping the second IP. The Standby VIM sends a periodic ping to its connected IP addresses. The ping allows the Standby VIM to ensure that the communication paths are valid. If the Standby VIM cannot verify the network path, an error message will be reported in DeltaV. The error message will indicate the Standby problems, and switchover will not be available. If the standby path is valid, you can command VIM switchover using DeltaV Diagnostics.

Note: Both Active and Standby VIM’s use a ping to determine presence of field devices. Note that by default the ping comprises the Modbus Diagnostics command. This command uses Function 8, Sub-Function Hi=0, Sub-Function Lo=0, and 2 bytes of data. The normal response to this command is to loop back the same data. Users can configure the standby VIM’s ping mechanism. The options are as follows: Default Ping, Customer Ping, ICMP Ping.

To better support the integration of the CSI 6500, MYNAH recommends using the custom ping:

This flag allows users to select any input dataset (one that uses Device Data Type of 0, 1, 2 or 3), and use it as the ping. By adding 10 to the Device Data Type of an input dataset indicates to the standby VIM that this dataset should be used as the ping. Instead of sending Function 8 command, the standby VIM will send the read command associated with the dataset. For example, if there is a dataset that reads Input Registers, it will be configured with a Device Data Type of 2. By changing the Device Data Type to 12 allows the standby VIM to use this dataset as a ping.

If the Active VIM loses communications with the first IP address, it starts using the second IP address and does not request a switchover. Only if both IP address connections are lost will the Active VIM request a switchover. The DeltaV controller verifies that the switchover is possible and then commands the currently Active VIM to go Standby, and at the same time commands the currently Standby VIM to go Active. Both VIMs maintain current DeltaV outputs. On switchover, the new Active VIM immediately starts scanning the field inputs to update its internal database.

Scenario 1 Operating Conditions

  • VIM A is active
  • VIM A is scanning 192.168.1.101 and Pinging 192.168.1.102
  • VIM B is pinging 192.168.1.101 and 192.168.1.102
VIM A StateVIM B StateRedundancy State
GoodGoodVIM A stays active if 192.168.1.101 or 192.168.1.102 are good
GoodBadVIM A reports standby problems – switchover unavailable
BadGoodVIM A requests a switchover to VIM B if both 10.22.6.50 and 10.22.6.51 are bad, and VIM B reports these connections as good.

Scenario 2 Operating Conditions

  • VIM B is active
  • VIM B is scanning 10.22.6.50 and Pinging 10.22.6.51
  • VIM A is pinging 10.22.6.50 and 10.22.6.51
VIM A StateVIM B StateRedundancy State
GoodGoodVIM B stays active if 10.22.6.50 or 10.22.6.51 are good
BadGoodVIM B reports standby problems – switchover unavailable
GoodBadVIM B requests a switchover to VIM A if both 10.22.6.50 and 10.22.6.51 are bad, and VIM A reports these connections as good.

Expected Results

For the tests below, the following diagnostics dataset registered are monitored in a DeltaV control module:

R33 Connected Device Mask
A bit set indicates the above reported IP address is connected. A bit clear indicates no connection or a failed connection. Bit 0 corresponds to IP address in register R1, Bit 1 corresponds to IP address in register R2, etc.

R36 Primary Device Status
Bit mask status of primary device connections. A bit value of 1 indicates connected, and a value of 0 indicated a disconnected device.

R37 Secondary Device Status
Bit mask status of secondary device connections. A bit value of 1 indicates connected, and a value of 0 indicated a disconnected device.

R38 Connected Device Mask from Partner
A bit set indicates the above reported IP address is connected. A bit clear indicates no connection or a failed connection. Bit 0 corresponds to IP address in register R1, Bit 1 corresponds to IP address in register R2, etc.

R39 Primary Device Status from Partner
Bit mask status of primary device connections. A bit value of 1 indicates connected, and a value of 0 indicated a disconnected device.

R40 Secondary Device Status from Partner
Bit mask status of secondary device connections. A bit value of 1 indicates connected, and a value of 0 indicated a disconnected device.

When R33 is greater than or equal to R38 the VIMs do not switch as the Active VIM connection integrity identified by R36, and R37 are better or equal to the connection integrity of the Partner VIM identified by R39 and R40.

6824R A: 10.1.98.47

6824R B: 10.1.98.57

1. Stable Normal Operation
Once the system is configured and normal operation is stable (no switchovers on any communication modules), allow the system to operate for 24 hours to verify that there are no intermittent switchovers on any of the communication devices. Follow standard troubleshooting techniques if unusual behavior is noted during this run-in period.

The system ran 24 hours as expected with a standard configuration highlighted in this manual.

2. Simulate Failed CSI 6824R A
With no random switchovers and the CSI 6824R A module as the primary, remove the primary CSI 6824R A module from the chassis to simulate a failed module. This should cause the CSI 6824R modules to switch and the VIMs should not switch.

In DeltaV Diagnostics, the partner VIM will report a failure to ping 6824R A.

The diagnostics registers identify a loss to 6824R A on both the Active and Partner VIM; data is not lost.

3. Simulate Failed CSI 6824R B
Once the 6824R switchover completes, and 6824R B assumes the primary role, re-install the removed 6824R and allow the system to stabilize. Repeat the previous test by removing CSI 6824R B from the backplane. CSI 6824R modules should switch and the VIMs should not switch.

In DeltaV Diagnostics, the partner VIM will report a failure to ping 6824R B.

The diagnostics registers identify a loss to 6824R B on both the Active and Partner VIM; data is not lost.

4. Simulate Failed Network Switch/Ethernet Cable (CSI 6824R A)
Once the 6824R switchover completes, and 6824R A re-assumes the primary role, re-install the removed 6824R and allow the system to stabilize. Unplug the Ethernet cable between the CSI 6824R A and the network switch. Communications on the CSI 6500 should switch and VIMs should not switch.

In DeltaV Diagnostics, the partner VIM will report a failure to ping 6824R A.

The diagnostics registers identify a loss to 6824R A on both the Active and Partner VIM; data is not lost.

5. Simulate Failed Network Switch/Ethernet Cable (CSI 6824R B)
Reconnect the Ethernet between 6824R A and the network. Allow the system to re-stabilize. Unplug the Ethernet cable between the CSI 6824R B and the first network switch. Communications on the CSI 6500 should switch and VIMs should not switch.

In DeltaV Diagnostics, the partner VIM will report a failure to ping 6824R B.

The diagnostics registers identify a loss to 6824R B on both the Active and Partner VIM; data is not lost.

6. Simulate Failed Interconnection Cable between Network Switches
Restore the system to a stable configuration with CSI 6824R A as the primary module. Disconnect the interconnection cable between the switches. This will prevent the CSI 6824R modules from seeing each other, simulating a failed or missing cable. There should be no communication switchover on either system. However, 6824R B should report a “94E10” error in the configuration software.

In DeltaV Diagnostics, the partner VIM will report a failure to ping 6824R A.

The diagnostics registers identify a Primary VIM connection loss to 6824R B and a partner VIM connection loss to 6824R A; data is not lost.

7. Simulate Failed Network Switch/Ethernet Cable (VIM A)
Restore the system to a stable configuration with CSI 6824R A as the primary module. Unplug the Ethernet cable between the VIM A and the switch. Communications on the CSI 6500 should not switch, but the VIM communication should switch.

In DeltaV Diagnostics, the previously Active VIM will report a failure to ping either IP address. The VIMs have switched in DeltaV Diagnostics.

The diagnostics registers identify a complete connection loss of the newly standby VIM; data is not lost.

8. Simulate Failed Network Switch/Ethernet Cable (VIM B)
Restore the system to a stable configuration with CSI 6824R B as the primary module. Unplug the Ethernet cable between the VIM B and the DeltaV Smart Switch. Communications on the CSI 6500 should not switch but the VIM communication should switch back to VIM A.

In DeltaV Diagnostics, the previously Active VIM will report a failure to ping either IP address. The VIMs have switched in DeltaV Diagnostics.

The diagnostics registers identify a complete connection loss of the newly standby VIM; data is not lost.


Contact

Please contact MYNAH for any questions about this integration at:

MYNAH Technologies
390 South Woods Mill, Suite 100
Chesterfield, MO 63017 USA
1.636.728.2000
support@mynah.com

DeltaV Virtual IO Module IOD-4111 - Modbus TCP IP Driver for DeltaV VIM2
Technical Notes

Viewing all articles
Browse latest Browse all 401

Trending Articles