| Expand | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
| Anchor | ||||
|---|---|---|---|---|
|
| Table of Contents | ||
|---|---|---|
|
...
Introduction
The RediGate Configuration Manual describes the configuration of many of the RediGate's standard features using the ACE program. This document gives additional instructions for configuring the RediGate to use the following protocols:
...
To configure as a UDP/IP Master, see RediGate UDP Protocol Master.
Modbus Protocol Description
This document is not intended to provide a detailed description of the protocol(s) involved, nor to disclose proprietary information that may belong to other parties. Depending on the protocol, it may be necessary to refer to other vendor protocol documentation or device configuration details to understand how the RediGate should be configured to interface with it. This section provides a brief discussion of the protocol for the purpose of understanding the RediGate's configuration objects.
...
The Description and Enabled properties are included in ACE as part of each object but are not mentioned here. The "UFF External" property is only mentioned for the objects where it is typically used, but should normally be left unchecked.
Modbus Master Channel
The structure of ACE objects for a Master Channel used for Modbus protocol is shown below:
...
| Include Page | ||||
|---|---|---|---|---|
|
AsyncCircuit, NetCircuit
As with most FieldUnit types, Modbus Master requires either an AsyncCircuit for serial (RS-232 or RS-485) devices or a NetCircuit for TCP/IP devices (TCP-Encapsulated Modbus or Open Modbus/TCP).
...
For general information on configuring circuits or AsyncPorts, see the RediGate Configuration Manual.
AsyncPort
If using an AsyncCircuit for serial devices, make sure to include an COM port (System → Networks → AsyncPort) object in the configuration with the instance number matching the physical COM port, and the baud rate corresponding to the field device’s setting.
See the RediGate Configuration Manual for information on configuring the AsyncPort.
Modbus FieldUnit
A Modbus FieldUnit object contains unique information for each physical field device that uses the Modbus communication protocol, defining parameters for how data is read and written for the device.
...
| Poll Table Properties | |
|---|---|
| Properties | Values |
| Source Register | Enter the starting source register in the device to begin polling data. This will be found in the documentation for the device, based on the information that you want to obtain. The format of the Source Register depends on the configuration of the Source Format, described below. For OFFSET source formats, the Source Register should be entered as a zero-based Offset (Coils or Holding registers only). For other Source Formats, the Source Register must be entered as a 5-digit absolute address. |
| Source Format | Select the data type of the data being read in this row of the Poll Table. See below for under Configuring Source Format for more details on this option. |
| Count | Enter the count of points to read from the device. For everything other than Strings, the Count includes the number of entities (Boolean, 16-bit, 32-bit, etc.) being requested, based on the Source Format setting listed above. This will typically also be the number of Destination Registers used by the poll. For String data types, the Count must be configured to match whatever convention is used in the Modbus device, and it must be defined such that the Modbus response contains the correct number of response registers (multiples of 8 bytes for String-8, multiples of 16 bytes for String-16, etc.). See below under “Configuring String Data Formats” for more details on the String data types. |
| Destination Register | Enter the starting destination register within the field unit's RTDB into which the Write Count of data points will be stored. These registers must be configured in the RTDB object. The Destination Register type should be chosen based on the Source Format of the data points defined on this row of the Poll Table:
|
| Comment | The Comment column is an optional field, allowing a description to be entered for each row in the table. This is only for the user and has no effect on the operation of the RediGate. |
Anchor ConfiguringSourceFormat ConfiguringSourceFormat
Configuring Source Format
| ConfiguringSourceFormat | |
| ConfiguringSourceFormat |
Different manufacturers use a variety of non-standard formats to represent data using the Modbus protocol. The RediGate provides many options to read and interpret data from a device in any byte order. Sometimes trial and error is necessary to get the configuration correct so that data is represented in the RTDB correctly.
...
| OFFSET Source Formats | Description | Meaning |
|---|---|---|
| OFFSET Coils 0 to 65535 | Binary (single bit) registerBinary (single bit) register | Use Modbus command 1 with offset (starting from 0) as the Source Register to request Boolean coils. |
| OFFSET 16 bit Hreg (HL) 0 to 65535 | Big Endian 16-bit register | Use Modbus command 3 for all following command formats. Typical 16-bit holding register, but requested with Source Register as an offset (starting from 0). |
| OFFSET 32 bit Hreg (hlHL) 0 to 65535 | Little-Big Endian 32-bit register | 32-bit holding register, with Source Register as an offset |
| OFFSET 16 BitPair L/B Endian (hl HL) 0 to 65535 | Little-Big Endian 16-bit pair of registers | 32-bit value stored as pairs of registers, requested with Source Register as an offset. Bytes transmitted in Little-Big Endian byte order (LSW first). |
| OFFSET 32 Bit B/B Endian (HLhl) 0 to 65535 | Big-Big Endian 32-bit register | Each of the OFFSET Source Format types use the same Endian notation as in the previous table of Source Formats. |
| OFFSET 16 Bit Pair B/B Endian (HL hl) 0 to 65535 | Big-Big Endian 16-bit pair of registers. | |
| OFFSET 16 Bit L Endian (LH) 0 to 65535 | Little Endian 16-bit register | |
| OFFSET 32 Bit L/L Endian (lhLH) 0 to 65335 | Little-Little Endian 32-bit register | |
| OFFSET 16 Bit Pair L/L Endian (lh LH) 0 to 65535 | Little-Little Endian 16-bit pair of registers. | |
| OFFSET 32 Bit B/L Endian (LHlh) 0 to 65535 | Big-Little Endian 32-bit register | |
| OFFSET 16 Bit Pair B/L Endian (LH lh) 0 to 65535 | Big-Little Endian 16-bit pair of registers. |
Examples of Source Format
The Endian source formats above define the byte order in which to interpret the data received from the Field Unit in response to the poll. A few illustrations are given below:
...
Starting Address = 40,001
Source Format might be "16 Bit Pair L/B Endian (hl HL)” or “16 Bit Pair B/B Endian (HL hl)”, depending on the word order of the registers. (If the odd numbered registers contain the most-significant word, then use the B/B Endian format.)
Count = 4 (this is the count of four 32-bit entities, not eight 16-bit registers)
Destination Register should be a 32-bit RTDB location.
| Anchor | ||||
|---|---|---|---|---|
|
The Modbus Poll Table includes several different types for String (ASCII) data. There is no common standard among Modbus devices as to how String data should be stored. The RediGate is only able to read String data in certain increments of ASCII characters (8, 16, or 32 bytes per destination RTDB register). The “Count” column indicates the count of registers that will be included in the Modbus message. As with all Modbus messages, a maximum of 255 total bytes per message are allowed.
...
| String Source Formats | Description | Meaning |
|---|---|---|
| String-8 (abcdefgh)String-8 (abcdefgh) | 8-character String request8-character String request | Request sets of four 16-bit registers, returning 8 ASCII characters, which should be stored into STRING32 or STRING256 RTDB registers. Only 8 characters are stored into each RTDB register (multiple register reads are stored into sequential RTDB string registers). Example: Omni flow computer in Omni mode returns 8 characters in response to a read request with Count=1. But in Modicon mode, you have to request a Count=4 registers in order to receive 8 characters. The RediGate Modbus driver will accept the bytes that are returned in whatever quantity, regardless of the mode, and store them into the RTDB in groups of 8 until the whole response message is processed. |
| String-8 Swapped (badcfehg) | 8-character String request, byte-swapped | Like the String-8, only each pair of bytes (MSB/LSB in each register) is reversed. Only 8 characters are stored into each RTDB register (multiple register reads are stored into sequential RTDB string registers). |
| String-16 (abcdefghijklmnop) | 16-character String request | Request sets of eight 16-bit registers, returning 16 ASCII characters, which should be stored into STRING32 or STRING256 RTDB registers. Only 16 characters are stored into each RTDB register (multiple register reads are stored into sequential RTDB string registers). |
| String-16 Swapped (badcfehgjilknmpo) | 16-character String request, byte-swapped | Like the String-16, only each pair of bytes (MSB/LSB in each register) is reversed. Only 16 characters are stored into each RTDB register (multiple register reads are stored into sequential RTDB string registers). |
| String-32 (abcdefghijklmnop) | 32-character String request | Request sets of sixteen 16-bit registers, returning 32 ASCII characters, which should be stored into STRING32 or STRING256 RTDB registers. Only 32 characters are stored into each RTDB register (multiple register reads are stored into sequential RTDB string registers). |
| String-32 Swapped (badcfehgjilknmpo) | 32-character String request, byte-swapped | Like the String-32, only each pair of bytes (MSB/LSB in each register) is reversed. Only 32 characters are stored into each RTDB register (multiple register reads are stored into sequential RTDB string registers). |
| OFFSET String-8 (abcdefgh) 0 to 65535 | 8-character String request, using Offset instead of register address | Like String-8, but the Source Register is an offset from register 40001, not an absolute address (using Modbus command 3). |
| OFFSET String-8 Swapped (badcfehg) 0 to 65535 | 8-character String request, byte-swapped, using Offset instead of register address | Like String-8 Swapped, but using Source Register as offset. |
| OFFSET String-16 (abcdefghijklmnop) 0 to 65535 | 16-character String request, using Offset instead of register address | Like String-16, but using Source Register as offset. |
| OFFSET String-16 Swapped (badcfehgjilknmpo) 0 to 65535 | 16-character String request, byte-swapped, using Offset instead of register address | Like String-16 Swapped, but using Source Register as offset. |
| OFFSET String-32 (abcdefghijklmnop) 0 to 65535 | 32-character String request, using Offset instead of register address | Like String-32, but using Source Register as offset. |
| OFFSET String-32 Swapped (badcfehgjilknmpo) 0 to 65535 | 32-character String request, byte-swapped, using Offset instead of register address | Like String-32 Swapped, but using Source Register as offset. |
Example of writing to String registers
All of the String Source Formats above apply to reading ASCII data, but what about writing strings? Because of the logic involved in processing Modbus write commands and the differences in how String polls are defined, the Poll Table must be defined carefully in order for String writes to be handled correctly.
...
- The three extra polls map each RTDB Destination Register to the starting Source Register explicitly. These polls do not need to be included in the Scan Table of the Master Channel, because they will not be read continuously. Their only purpose is to map outputs for write commands.
- The non-scanned polls must be defined in reverse order based on Destination Register.
- The non-scanned polls must be defined above the scanned poll (higher in the table). This allows the poll table lookup to find a match for the RTBD register and map to the correct Source.
Modbus RTDB
See the RediGate Configuration Manual for information on configuring the RTDB.
Modbus Specific Outstation (SOS)
The Master Channel, Circuit, Field Unit, and RTDB object properties are generally very similar for all Field Units, independent of the protocol being used. This is designed so that a common structure is used for handling protocols in a similar way. However, depending on the protocol, sometimes it is necessary to have special protocol-specific options for the Field Unit. Rather than modifying the common channel structures, it is preferred to have an additional object that defines these special characteristics.
...
| Properties | Values |
|---|---|
| Poll Modification Defs | Click the Edit Table button to define the special characteristics needed for the Modbus protocol modification on this Field Unit. |
| Poll Index | This refers to the poll numbers defined in the Field Unit Poll Table. The poll message whose number appears in this row will be modified as specified in the remainder of this row. If several rows refer to the same poll number, all modifications will be evaluated before modifying this poll transmit message, in case one condition specifies "no modification". |
| Trig. Addrs | Enter the Modbus address location in this RTU's RTDB to use for a Trigger Address. If the Trig Address contain the exact value as specified in the "Trig Value" parameter, then this SOS row becomes active, and the modification of this poll message will take place. The values in the Trig Address RTDB registers may be modified by a polling process, or by ISaGRAF or POD logic. |
| Trig. Value | Enter the value which, if found at the Trig Addrs. location, will cause the poll message modification to take place. This value may be between 0 and 65535 inclusive. If the Trig Addrs is a Boolean register, the valid values are 0 and 1. |
| Tx Start Byte | Unless using a "Skip" option for the Fill Control, the SOS table allows bytes in a Modbus message to be modified before the poll is sent. The poll byte modification is controlled by the Tx Start Byte, Tx #Bytes Filled, Fill from Addrs. and Fill Control parameters. Enter the starting byte of the Modbus poll command to be modified. Modbus poll Tx bytes that might be used for this option typically include:
|
| Tx #Bytes Filled | Enter how many bytes in the poll command are to be modified starting at the Tx Start Byte. |
| Fill from Addrs | Enter the Modbus location in the RTDB containing the bytes to use for the poll modification. The values in this RTDB location(s) should be filled as required, before the Trigger occurs, either by ISaGRAF, an external host, or as the result of another poll to the Field Unit. |
| Fill Control | This parameter allows certain variations when executing the self-modifying poll. If either of the "Skip" options is used, the poll is either skipped or not skipped based on the value of the Trig. Addrs. Otherwise (if using a non-Skip option on this SOS table row), bytes in the Modbus poll will be modified before sending to the device. This can be useful for some complex operations, such as working with non-standard Modbus in certain flow computers. Options available for this parameter are: No Conversion (LSB first) - Bytes from the Fill from Addrs registers are used with no conversion, as 16-bit values. Byte Swapping (MSB first) - Bytes from the Fill from Addrs. Register are put into the transmit message MSB first, followed by LSB. Fill using LSB only - Use this option if the Fill from Addrs register contains an 8-bit value rather than a 16-bit value, so that the most-significant byte is omitted. If more than one byte is modified (Tx #Bytes Filled > 0), the subsequent registers will be used as the source of the additional bytes. Skip Poll if Matching Trigger - Selecting this option causes the poll not to be sent if the value in the Trig Addrs matches the Trig Value (NOTE that no byte modification occurs in this case). When selecting this option, the other values in this row of the Poll Modification Def must be set to dummy values but will not be used. Skip Poll on NON-Matching Trigger – If the Trigger register contains a zero value, then ignore. If the trigger register is non-zero, skip the poll. |
| Extra Logic | This option gives some additional options that may be used in the Modbus poll modification. None – Choose this option to disable Extra Logic. Ignores the parameter RTDB for Poll Length. Save Reply Length to RTDB – Use last field to save byte count of the Modbus reponse packet length. Incr-FillRtdb+Decr-SaveRtdb – The Fill from Addrs RTDB register is incremented after the poll happens. The next consecutive RTDB register is decremented (assuming that the poll was successful.) See section RediGate-Modbus-MasterModbus Flow Computer SOS Example for an example of how this "Incr-FillRtdb+Decr-SaveRtdb" option would be used. |
| RTDB for Poll Length | Enter the Modbus address into which you want put the byte length of the response. This is very useful if your command is requesting data of unknown length such as "all alarms", etc. You will know how many bytes were returned in response to your command by looking at this address after the poll response has been processed. If you don't wish to use this feature, set the Extra Logic field to "None". |
Simple Modbus SOS Examples
Following is an example of the self-modifying poll feature using the Modbus SOS table. In this example, two different polls are modified:
...
NOTE: More than one SOS row can apply to modify the same Poll Table entry, and more than one condition can be satisfied simultaneously to modify the same poll. If more than one condition is satisfied at the same time so that the same bytes in a poll would be modified, the last condition in the list takes precedence. However, if the "Skip Entire Poll" condition is satisfied, this takes precedence over all other conditions and causes the poll not to be sent.
Modbus Flow Computer SOS Example
Following is an example of a more complex use of the Modbus SOS table, using it to deal with a Modbus flow computer with event buffers. Some flow computers report event records using a custom variant of the Modbus protocol, whereby the Modbus protocol "Count of registers" field is used to request one flow computer event record of data, not a number of registers. The record is returned as a fixed sequence of a certain number of data bytes, as defined in the flow computer.
...