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:

• Modbus RTU (serial) Master
• Modbus ASCII (serial) Master
• Modbus RTU (TCP) Master
• Modbus ASCII (TCP) Master
• Open Modbus/TCP Master

See the following Quick Start example configurations:

• Serial Modbus RTU Master
• Open Modbus TCP Master

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.

Modbus is a poll-response (or master-slave) protocol. Modbus protocol devices are addressed with a number from 1 to 255. A host system requests data from a Modbus device using a Function Code, a zero-based Offset, and a Count of registers. The Function Code determines the type of data, and the Offset specifies which starting register to request within that data type, starting from 0. The device will respond to a request by returning the specified Count of registers. Traditionally, Modbus device vendors use a 5-digit Address notation to refer to these registers (for example, 40,001); however, some manufacturers use the Function/Offset method or a different non-standard Address notation to identify registers (such as 400,001).

Typical Modbus address registers and function codes are listed below, along with the traditional Starting Address notation.

For example, using a Function Code=3, Offset=0, and Count=6 would request the registers commonly notated as 40,001-40,006. The following message shows this poll and response for a device number 21 (0x15). The values returned from the registers in this example are 0001 through 0006 (underlined below).

Poll:     15 03 00 00 00 06 C6 DC
Response: 15 03 0C 00 01 00 02 00 03 00 04 00 05 00 06 C8 20

Holding Registers and Input Registers commonly hold 16-bit data. Often, pairs of 16-bit registers are also used to represent 32-bit integers or floating point data.

For instance, in a device that uses register pairing, the host might request 41,001 and 41,002 (two 16-bit values), and the host is responsible for assembling them into a single 32-bit value. The first register might contain the most-significant 16-bit word (big-endian), or it might contain the least-significant 16-bit word (little-endian), depending on the design of the device.

In other devices, a single register (e.g., 41,001) might return a 32-bit value per address location. Or it might use analog registers to contain packed Booleans, one or two ASCII character strings per register, etc.  The system designer must become acquainted with the data and address format used by a Modbus device in order to correctly configure the RediGate to request and interpret the device data.

The Modbus master/host must be configured according to the requirements defined by the device. The RediGate has a very flexible and full-featured configuration that allows it to communicate successfully with nearly all Modbus devices.

Modbus ASCII is an older ASCII-based protocol that uses a less robust LRC error checking algorithm. It is not used much anymore.

Modbus RTU (or Modbus Binary) is the most common protocol for Modbus over serial communications and uses a more robust CRC error checking. The RediGate can do Modbus ASCII or RTU over a serial (RS-232 or RS-485) circuit.

Modbus TCP-Encapsulated – The RediGate can encapsulate either RTU or ASCII Modbus protocol into TCP/IP packets (this would be suitable for communication to a Modbus device through a Terminal Server).  This includes the Modbus CRC at the end of the message. The TCP port number is user-definable.

Open Modbus/TCP is a variation of Modbus RTU that is only used for TCP/IP networks. It uses the same basic message structure, but it adds 6 bytes to the beginning and removes the CRC from the end of each message. Open Modbus/TCP uses TCP port 502 as standard.

The following sections describe the ACE objects used for Modbus Master, object properties (including constraints on the Instance number), and object fields and their possible values required to configure for the given protocol(s). The object structure in ACE is hierarchical, with each object existing under a certain parent object. For instance, the FieldUnit is the child of one of several types of Circuit objects, either serial or network type (" System>Clients>Master Channels>Master Channel>Circuit").

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:

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 the AsyncCircuit, choose the serial port to use for the communication (COM2 on RediGate 100 series, or one of several COM ports on the RediGate 400 series).

For the NetCircuit, use a Circuit Type of “Network Circuit" and set the Master Network Port to be the TCP/IP port number used by the device for Modbus communication (if using Open Modbus/TCP, this should typically be port 502). Enter the Destination Address (device IP address) in the Connect Table.

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.

Configuring Source Format

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.

Modbus protocol typically transmits each 16-bit value in “big endian” format (most significant byte, MSB, is transmitted first, followed by the least significant byte, LSB).  When requesting 32-bit values, there is no universal standard for how 32-bit Modbus is to be transmitted on the wire. Either the most-significant word (MSW) or least-significant word (LSW) may be stored in the device first, and thus transmitted first in the Modbus protocol messages.

The Poll Table list includes a mnemonic device ("HLhl") and a verbal description of each source format, to help the user identify the different Source Formats.

• The “H” and “L” indicate the relative positions of the high and low bytes within each word.
• “HL” and “hl” indicate the relative positions of the high and low order 16-bit words.
• Thus, the Source Format labeled “Little-Big Endian (hl HL)” indicates the data is interpreted as LSW first followed by MSW; whereas “Big-Big Endian (HL hl)” indicates the data is interpreted as MSW first followed by LSW. These are the two most common methods of polling 32-bit data from Modbus devices.

The following tables give a list of the Modbus Source Format options with an explanation of each.  The formats listed in Bold Italic are the more commonly used selections. For each non-OFFSET format, the Source Format column should contain an absolute address (10,001, 40,001, etc.).

The following “OFFSET” formats are equivalent to the Source Format types above in byte and word order, but they allow the configuration to identify the source register using the "Function Code / Offset" convention. The OFFSET type of Source Format is sometimes necessary for Modbus devices that have coil registers greater than 9999 or holding registers numbered higher than an offset of 25,534 (i.e., higher than an absolute address of 65535).

For each OFFSET type, the Source Format column should be configured as a number from 0 to 65535, which is an offset from the first coil register (function code 1) or the first holding register (function code 3). Only Modbus commands 1 and 3 are currently supported for reading OFFSET types (with corresponding Modbus write function codes 5, 6, 15, and 16).

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:

Example #1:
Field device includes ten 16-bit integers, transmitted in normal Modbus format, starting at the address 40,001.  Poll Table should be configured for:

Source Register = 40,001
Source Format = 16 bit register (HL)
Count = 10
Destination Register should be a 16-bit RTDB location.

Example #2:
Field device includes four IEEE floating point values, stored in registers 40,001-2, 40,003-4, 40,005-6, and 40,007-8.  Because the registers are listed as odd-numbered registers, the device is using pairs of 16-bit registers to represent the 32-bit IEEE values. Thus, the Poll Table should be configured for:

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.

Configuring String Data Formats

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.

For example, if the Modbus device stores ASCII characters in 16-bit registers (two characters per register), then for the String-8 data type you must poll for multiples of 4 source registers (“Count” in the Poll Table should be 4, 8, 12, etc.). For the String-16 data type, the “Count” should be 8, 16, 24, etc.

However, if the Modbus device stores ASCII characters in 32-bit registers (four characters per register), you still need to set the “Count” to poll for multiples of 32-bit registers, so that the response comes back in groups of 8, 16, or 32 ASCII characters, depending on the Source Format chosen (for instance, for String-8 data use a count of 2, 4, 6, etc.). Or, if a single Modbus register contains the entire string, the count should be 1 per string register.

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.

Below is an example of a Poll Table containing a command to read String-8 registers from a device that stores ASCII data with two bytes per 16-bit register. The Poll Table reads 12 registers from the device, receives 24 bytes in response, parses the message into three String-8 values, and stores the resulting data into 48001-3 (40033‑36 à 48001, 40037‑40 à 48002, and 40041‑44 à 48003).

If a host writes to 48001, the RediGate Modbus driver will correctly write the four registers (40033‑36) back to the device. But writing to 48002 or 48003 will not work correctly. In order to make all of the String registers write to the correct locations, there must be additional polls defined in the Poll Table (which do not need to be scanned in the Scan Table), as follows:

Note the following about the Poll Table above:

• 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.

The SOS object contains additional features specific to a particular Field Unit protocol. In this document, "SOS" stands for "Specific Outstation," meaning specific properties that may be unique for a given protocol. This section describes the SOS object for Modbus units. Field Units using protocols other than Modbus may have their own unique SOS object defined.

The Modbus SOS object is a powerful, complex tool which allows a user to modify the normal structure of the Modbus polling protocol, based on results of preceding polls, or based on controls that are received from a Modbus host or ISaGRAF logic. Criteria can be specified which, if true, cause the polls defined in the Modbus Poll Table to be modified or skipped. This is useful in certain applications, such as reading log data from certain Modbus flow computers. This feature is sometimes referred to as "self-modifying polls".

If these special additional capabilities of the Modbus polling are not needed, this object may be omitted from the configuration.

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:

• Poll index 1 has its the Modbus "Count" of registers dynamically modified based on the contents of another RTDB register
• Poll index 2 is enabled or disabled based on the contents of an RTDB register

A Modbus Field Unit is defined with the following polls in its Poll Table, which would typically generate Modbus messages to read the indicated number of registers from the Modbus field device.

Next, the Modbus SOS table is defined as follows:

Poll 1 When the Modbus register 10,100 is set to a value of 1 (Trig Value), this causes the first SOS row to become active. At this point, the next time the Master Channel tries to send the poll with Poll Index 1 for this field unit, that poll will be modified from its normal Poll Table definition before sending to the field Unit. The poll will continue to be scanned until register 10,100 is set to a different value.

The modification takes the value contained in this Field Unit's RTDB register 40,201, and substitutes the bytes 5-6 in the Modbus poll (based on the TX Start Byte and TX #Bytes Filled). In the format of the Modbus poll definition, bytes 5 and 6 include the "count of registers" to read. Based on the Poll Table definition, this would be a default count of 10 registers (0x000A), but now those bytes will taken from register 40,201 in order to build the Modbus message.

For this example, consider that register 40,201 contains a value of 8 (0x0008). Because "Byte Swapping" is selected, the modified byte 5 in the Modbus message is taken from the MSB (0x00) of register 40,201, and the modified byte 6 in the Modbus message is taken from the LSB (0x08) of register 40,201. The poll number 1 sent to the Field Unit is thus modified as follows:

Original poll: 01 03 09 60 00 0A + CRC Modified to: 01 03 09 60 00 08 + CRC

Note that the new checksum will be calculated to match the modified poll, so that the poll can be validated in the remote device. When a response is received from the Field Unit, the count of bytes received will be stored in the "RTDB for Poll Length" register 40,233.

Poll 2 When the Modbus register 40,001 (Trig Addrs) is set to a value of 20 (Trig Value), the second row in the SOS table is activated. This could be done externally by a communication process, by the user MMI, or using a Pre-Initialized RTDB ACE object (see Pre-Initialized RTDB).

When the Master Channel attempts to send Poll Index 2, it checks the SOS table and determines that the trigger for Poll Index 2 is active (matching the Trig Value). Thus, even though the Poll Table and Master Channel Scan Table would have activated this poll to be sent, the SOS table causes the poll to be blocked, so it the poll is skipped until the Trig Value changes to something other than its active value.

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.

The Modbus SOS table is used to modify the Modbus Field Unit polling to request from the flow computer a certain number of the event records, and it may also be used to "roll back" to a previous event record. The Poll Table needs to be defined to poll for the particular "register" in the flow computer that is used as a pointer into the event buffer.

An example of the SOS table definition is shown below. Two rows are used in the SOS table. In this case, the "Poll Index" is defined to be 14 in the example but should be set appropriately for your Poll Table.

When the register 40,152 (Trig Addrs) is zero, the poll index 14 is skipped. When you want to trigger the poll to happen, store into register 40,151 the index number of the starting event record to read, and store into register 40,152 the number of event records to read. 
With the Trig Addrs non-zero, the SOS table will activate poll index 14 the next time it's scanned by the Master Channel. Because the Extra Logic option is set to the special "Incr- FillRtdb+ Decr- Save Rtdb" setting, the following actions will be taken:

• The Modbus poll bytes 5 and 6 (event index) are replaced with the value contained in 40151. Then the poll is sent to the flow computer.
• When the poll response is received, register 40,001 contains the number of bytes of data included in the response.
• The value in Register 40,151 (Fill from Address) is automatically incremented by one in preparation for the next event number to be retrieved.
• The next consecutive Register (40,152) is automatically decremented by one (until it becomes zero).
• On the next scan of poll index 14, the next consecutive event record is retrieved, and so on until the Trig Addrs register becomes zero.
• Because register 40,152 is used as the Trig Addrs for both polls, once it is decremented to zero, the first SOS record causes poll index 14 to be skipped until the trigger registers are populated again, and the process starts over.
• Note that the "Skip poll" row for Poll Index 14 is configured above the "Byte Swap" row. If the poll is skipped because of the trigger (register value at 40,152 = 0), then the second SOS poll modification row has no effect.