Collapse
CollapsingX
  • - or -

Modbus data configuration


Before filling out data fields (entries) start with a description of the data that will be passed to and from the runtime platform (for example, data type and minimum and maximum values expected). In some cases, the entries are predefined by some existing ladder logic; in other cases, you are setting up a new automated system and can organize the data the way you want.

Typically, you use data fields of the same data type.

Many legacy automated systems use several 16-bit "tags" or registers to transfer all information, including single-bit status-type information or larger floating-point information. With these systems, floating-point values are often scaled (for example, 3.3234, multiplied by 1000, is represented as the short integer 3323). Some will also use single bit "coils" for setting control and reading status.

Software-based SCADA and SoftPLCs often use several 32-bit "tags" or registers to transfer information. In Matrox Design Assistant, 16-bit and 32-bit "tags" are referred to as Short and Integer values, respectively.

Modbus data fields

In the ModbusReader step and ModbusWriter step, you describe the data that will be transferred as a set of data fields (or entries). Each data field has:

  • A name. Usually named from the perspective of the PLC.

  • A data type. Indicates the size and format of the data field.

  • A Modbus table. Indicates the data table (on the runtime platform or the remote slave device) of the data field. The available tables are dependent on the data type specified. For instance, the BitStatus data type is associated with the coil and discrete input tables; while all other data types use the holding or input register data tables.

  • A register number. Identifies the specific entry in the table. Register numbers in Matrox Design Assistant start at 1 and increment for each entry. For holding and input registers, each entry is 16-bits, so each 16-bit block in the table is numbered 1 more than the previous (for instance, 1, 2, 3, 4). When the 16-bit registers are used for 32-bit data types, they are numbered 1, 3, 5, 7. For more information, see the Register number consistency across Modbus devices and standards subsection of this section.

  • A value. Only used in the ModbusWriter step. Values are typically linked to an output of another step. When writing data into Short registers, be aware of the limits of 16-bit values (-32768 to 32767). If you try writing an out of range value (for example, a continuous counter), it will cause an error.

Register number consistency across Modbus devices and standards

There is not always consistency in the terminology or numbering of the Modbus protocol and its documentation. In Matrox Design Assistant, a register number for a table starts at 1 and increments for each successive entry. For the 16-bit tables holding 32-bit or 64-bit data types, such as integers or doubles, respectively, the register number increments in multiples of 16-bit registers. For instance, a holding register of type double (a 64-bit data type), will increment as follows: 1, 5, 9, 13. A holding register of integers will increment in the following manner: 1, 3, 5, 7.

When programming a PLC or other Modbus device, remember that the device might use a different numbering scheme for the same data. For example, a block of data comprising 4 values (X, Y, Angle, and Status), in a holding register on the runtime platform, could be stored as 4 16-bit registers. The PLC could use the numbering scheme 40000, 40001, 40002, and 40003 to represent the 4 values; while Matrox Design Assistant would use 1, 2, 3, 4. Alternatively, the same block of data, this time exchanged as 4 32-bit values on a SCADA system, would be numbered 0, 1, 2, 3 in the SCADA program and 1, 3, 5, 7 in Matrox Design Assistant.

When using Matrox Design Assistant, any expressions or steps that refer to a register number found in a ModbusReader step or ModbusWriter step must use the Matrox Design Assistant numbering scheme, regardless of the numbering scheme being used by any other device in the automated system using the Modbus protocol. See the Modbus example section later in this chapter for an example.