Default Node Parameters The Default Node Parameters group gives the user the option to change any of the default node parameters in the group for all of the checked nodes. After the configuration file is created the should be run to refine the parameter settings for each node separately (see the chapter for a detailed description of the node parameters). Save The Save screen of Modbus Ethernet Configuration File Generator provides the user a preview of the contents of the interface configuration file and the ability to set the name and location of the file when it is saved: File Name The File Name field must contain the entire path and file name of the interface configuration file to be generated. A user can either enter it directly into the File Name field or search for it by clicking the Browse button. Browse The Browse button gives the user the option to search for the full path and name of the interface configuration file with the standard Microsoft Windows open file dialog. In this way a user can get the entire path and file name without having to enter it into the File Name field. Save To generate the interface configuration file click the Save button. Once the file has been saved the Next button will be enabled and the text in the button will change to Finish. Preview The Preview list shows the exact contents of what will be saved to the interface configuration file. The following image shows how the Save screen of the Modbus Ethernet Configuration File Generator will appear after the interface configuration file has been saved: At this point the interface configuration file has been generated and saved, and none of the previous operations can be repeated. The should now be run from the ICU after creating a new interface instance (see ) using the newly created Interface Configuration File as input. This will allow the user to refine the parameter settings for both the interface and each Ethernet node in the interface configuration file.
Data Type 16 This parameter (/swap16) is used only in conjunction with points of data type 16 (see section ). String This parameter (/swapstring) is used only in conjunction with points of string data types (see section ). TCP/IP Header Since some Modbus TCP/IP systems may not support the standard Modbus Application Protocol (MBAP) header, an optional parameter (/hcp) is provided so that the message packets do not use the standard header (see for more details): Node Trace The trace group of buttons and fields gives the user the ability to turn on and off debug tracing for particular actions and data in the interface for the selected Ethernet node. In general, tracing need only be turned on when instructed by OSIsoft technical support personnel. Tracing is described in more detail in the section (/debug=#). Requests Trace the Modbus request buffers. Responses Trace the Modbus response buffers. Scan Lists Trace the scan list processing control. Tag Groups Trace the tag groups that represent a group of tags to request. Device Points Trace the device points that represent a tag in the interface. Tags Trace the tags (i.e. PI points) in the interface. Communications Trace the general flow of communications such as opening, closing and reconnecting Ethernet nodes.
[UFO2_STATE:#] (IF-Node2) Optional State 2 Tag The ExDesc must start with the case sensitive string: [UFO2_STATE:#] The number following the colon (:) must be the Failover ID for the interface running on IFNode2 The failover state tag is recommended. Normally updated by the Interface currently in the Primary state. Values range between 0 and 5. See description of State 1 tag.
This counter does not include the amount of time to send the data to PI. This point is similar to the [UI_SCINDEVSCANTIME] Health Point. The ICU uses a naming convention such that the tag containing “(Scan Class 1)” (for example, “sy.perf.etamp390.E1 (Scan Class 1).device_scan _time” refers to Scan Class 1, “(Scan Class 2) refers to Scan Class 2, and so on.
UniInt Failover Specific Error Messages Informational Message 16-May-06 10:38:00 modbusE 1> UniInt failover: Interface in the “Backup” state. Meaning Upon system startup, the initial transition is made to this state. While in this state the interface monitors the status of the other interface participating in failover. When configured for Hot failover, data received from the data source is queued and not sent to the PI Server while in this state. The amount of data queued while in this state is determined by the failover update interval. In any case, there will be typically no more than two update intervals of data in the queue at any given time. Some transition chains may cause the queue to hold up to five failover update intervals worth of data. Message 16-May-06 10:38:05 modbusE 1> UniInt failover: Interface in the “Primary” state and actively sending data to PI. Backup interface not available. Meaning While in this state, the interface is in its primary role and sends data to the PI Server as it is received. This message also states that there is not a backup interface participating in failover. Message 16-May-06 16:37:21 modbusE 1> UniInt failover: Interface in the “Primary” state and actively sending data to PI. Backup interface available. Meaning While in this state, the interface sends data to the PI Server as it is received. This message also states that the other copy of the interface appears to be ready to take over the role of primary.
Function Code 1: Read Coils Request PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x01 Starting Address 2 Bytes 0x0000 to 0xFFFF Quantity of Coils 2 Bytes 1 to 2000 Response PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x01 Byte Count 1 Byte N = Quantity of coils / 8 Coil Status N Bytes Value(s) Function Code 2: Read Discrete Inputs Request PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x02 Starting Address 2 Bytes 0x0000 to 0xFFFF Quantity of Inputs 2 Bytes 1 to 2000 Response PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x02 Byte Count 1 Byte N = Quantity of inputs / 8 Input Status N Bytes Value(s)
Function Code 3: Read Holding Registers Request PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x03 Starting Address 2 Bytes 0x0000 to 0xFFFF Quantity of Registers 2 Bytes 1 to 125 Response PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x03 Byte Count 1 Byte 2 * N (Quantity of registers) Holding Registers N * 2 Bytes Value(s) Function Code 4: Read Input Registers Request PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x04 Starting Address 2 Bytes 0x0000 to 0xFFFF Quantity of Registers 2 Bytes 1 to 125 Response PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x04 Byte Count 1 Byte 2 * N (Quantity of registers) Holding Registers N * 2 Bytes Value(s)
Function Code 5: Write Single Coil Request PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x05 Output Address 2 Bytes 0x0000 to 0xFFFF Output Value 2 Bytes 0x0000 or 0xFF00 Response PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x05 Output Address 2 Bytes 0x0000 to 0xFFFF Output Value 2 Bytes 0x0000 or 0xFF00 Function Code 6: Write Single Register Request PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x06 Register Address 2 Bytes 0x0000 to 0xFFFF Register Value 2 Bytes 0x0000 to 0xFFFF Response PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x06 Register Address 2 Bytes 0x0000 to 0xFFFF Register Value 2 Bytes 0x0000 to 0xFFFF
Function Code 15: Write Multiple Coils Request PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x0F Starting Address 2 Bytes 0x0000 to 0xFFFF Quantity of Outputs 2 Bytes 1 to 1968 Byte Count 1 Byte N = Quantity of outputs / 8 Outputs Value N Bytes Value(s) Response PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x0F Starting Address 2 Bytes 0x0000 to 0xFFFF Quantity of Outputs 2 Bytes 1 to 1968 Function Code 16: Write Multiple Registers Request PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x10 Starting Address 2 Bytes 0x0000 to 0xFFFF Quantity of Registers 2 Bytes 1 to 123 Byte Count 1 Byte 2 * N (Quantity of registers) Outputs Value N * 2 Bytes Value(s) Response PLC Node Address 1 Byte 1 to 255 Function Code 1 Byte 0x10 Starting Address 2 Bytes 0x0000 to 0xFFFF Quantity of Registers 2 Bytes 1 to 123
Tag Configuration Optimization Since the interface will assemble related tags with contiguous data offsets into groups in order to maximize the number of tag values requested in a single Modbus write command, it is best for the user to configure related tags in a manner in which tag groups can be leveraged to minimize the number of requests to write the tag data. In other words, the more related tags whose data offsets are contiguous, the better. NOTE: In some cases it may necessary that an output tag within a group of contiguous tags have a source tag dependency that will have a detrimental effect on the timely update of all of the tags in the group. In that case the output tag can excluded from optimization by use of the descriptor in the attribute of the tag. For example, assume that a user creates 200 tags with the attribute values specified in the following table: Point Attribute Description Value Instrument Tag Ethernet node COM3 Location 2 PLC Node 2 Location 3 Write multiple registers containing 16-bit integer 116 Example 1 If the 200 tags have data offsets of 1 to 40, 51 to 90, 101 to 140, 151 to 190 and 201 to 240 respectively, the tags will be represented by five tag groups. The following table represents the five tag groups and the consecutive offsets in each group: Tag Group Tag Offsets 1 1 to 40 2 51 to 90 3 101 to 140 4 151 to 190 5 201 to 240 In this case five requests will have to be made to write the values for the 100 tags. Example 2 If the 200 tags have data offsets of 101 to 300, the tags will be represented by two tag groups: tag groups 1 and 2. The following table represents how the tags will be located in the two groups: Tag Group Tag Offsets 1 101 to 223 2 224 to 300 In this case two requests will have to be made to read the values for the 100 tags since the maximum number of values in a single write request is 123.