Modbus TCP Examples

Included with the DataMan Setup Tool installer are two example PLC programs created with CoDeSys v2.3 software. These samples are designed and tested on a Wago 750-841 PLC. These programs demonstrate the DataMan ID readers’ capabilities and proper operation. You can do the same operations by using more advanced features and efficient programming practices with Wago PLCs. The examples try to show different approaches in the techniques used for the communication to the DataMan reader and they are better for demonstration purposes.

Note: All examples are designed to work only if the “Control” datablock is mapped to the Coil space and the “Status” datablock is mapped to the Discrete Input space.

ApplicationLayer Example

This sample realizes a generic data transfer between the DataMan reader and the PLC. Memory areas of the “Control”, “Status” and “Output Area” are cloned in the PLC and synchronized cyclically, or as needed. Each data area is synchronized with its own instance of “ETHERNETMODBUSMASTER_TCP”. This causes three TCP connections to be open simultaneously. Make sure that the Modbus TCP related setting “Maximum Connections” on the DataMan reader is set to at least 3 for this example to work.

Function

The example application demonstrates the following operations:

  1. Transfer the 32-bit “Control” register data from the PLC to the reader.
  2. Transfer the 32-bit “Status” register data from the reader to the PLC.
  3. Transfer “Output Data” from the reader to the PLC.

All actions are started when there is a connection to the reader.

Transferring “Control” Register Data

All data gets transferred when there is a change in the local PLC data. The local PLC data can be manipulated in the visualization.

Note: No synchronization is implemented from the reader to the PLC, so the local PLC data can be incorrect after building up the connection or if another Modbus TCP client manipulates the Contol register simultaneously. There is a timeout setting that can lead to a disconnect if you do not manipulate the “Control” register during this timeframe.

Transferring Status Register Data

All data gets transferred cyclically. The poll interval can be specified in the visualization.

Transferring Output Data

All data gets transferred cyclically. The poll interval can be specified in the visualization.

DataManControl Example

This sample shows in a sequential manner the steps to do to achieve one of the functions named in the following subsection. To outline this chronological sequence, “Sequential Function Chart” is used as programming language.

Function

The example application demonstrates the following operations:

  1. Triggering a read
  2. Getting read results
  3. Executing string commands (DMCC)
  4. Executing SoftEvent operations
    1. Train code
    2. Train match string
    3. Train focus
    4. Train brightness
    5. Untrain
    6. Execute DMCC
    7. Set match string

The “Main” program contains variables to invoke each of these operations. The operation is invoked by toggling the control bool directly or from the visualization (red=0, green=1) from 0 to 1. This will invoke the associated subroutine to perform the operation. When the operation 4 is complete, the subroutine will set the control bit back to 0.

Triggering a Read

The example provides a “Continuous Trigger”. As the name implies, enabling the “xTrigger” bit will invoke a continuous series of read operations. Once enabled, the “xTrigger” control bit will remain set until you disable it.

Primarily, the trigger subroutine manages the trigger handshake operation between the PLC and the reader. The control Result Ack and Trigger bits are reset, the Trigger Enable bit is set, the PLC waits for the corresponding TriggerReady status bit from the reader, and the control Trigger bit is set. Refer to a description of handshaking in section Operation.

Getting Read Results

For this example the operation of triggering a read and getting read results was intentionally separated. This is to support the situation where the PLC is not the source of the read trigger. For example, the reader may be configured to use a hardware trigger. In such a case, only the get results subroutine would be needed.

Like the triggering subroutine, the get results subroutine manages the results handshake operation between the PLC and the reader. The routine waits for the ResultsAvailable status bit to become active, it copies the result data to internal storage, and then executes the ResultsAck handshake. Refer to a description of handshaking in section Operation.

The read result consists of a ResultCode, ResultLength, and ResultData. Refer to section Output Data Block Field Descriptions for details of the ResultCode values. The ResultLength field indicates how many bytes of actual result data exist in the ResultData field. The subroutine converts this byte length to word length before copying the results to internal storage.

Execute String Commands (DMCC)

The string command feature provides a simple way to invoke DMCCs from the PLC. The command format and command result format is exactly identical to that used for serial or Telnet DMCC operation.

This subroutine copies an example DMCC (||>GET DEVICE.TYPE) to the String Command block and then manages the string command handshake operation between the PLC and the reader to invoke the command and retrieve the command result. Any valid DMCC command may be invoked with this mechanism. Refer to the DataMan Command Reference document available through the Windows Start menu or the Setup Tool Help menu.

Execute SoftEvents

SoftEvents are used to invoke a predefined action. Each SoftEvent is essentially a virtual input signal. Each of the SoftEvent subroutines manages the handshake operation between the PLC and the reader to invoke the predefined action. The associated action is invoked when the SoftEvent bit toggles from 0 to 1. The subroutine then watches for the associated SoftEventAck bit from the reader which signals that the action is complete. For a description of handshaking, see section Operation.

Note: The “Execute DMCC” and “Set Match String” SoftEvents make use of the Input Data block. The subroutine for these two events copies the relevant data into the User Data fields of the Input Data block and then invokes the User Data subroutine to transfer the data to the reader. Only after the user data is transferred is the actual SoftEvent action invoked. It is required that the user data be transferred before invoking either of these events.
Note: The “Train Match String” SoftEvent only prepares the training mechanism. The actual training occurs on the next read operation. Therefore, a trigger must be issued following “Train Match String”.