Devices

Table of Contents

• Device Communication
• Reconnecting Devices
• Accessing Devices
  • Modbus TCP Devices
  • Modbus RTU Devices

See also

I/O Components in the Xentara user manual

Devices are a type of Xentara I/O components. Each device represents a single Modbus server that can be accessed using the Modbus protocol.

The Xentara Modbus driver distiguished between two types of devices:

• Modbus TCP devices are accessed over the network using Modbus TCP
• Modbus RTU devices are accessed over a serial line using Modbus RTU

Modbus RTU devices must be placed within an RTU bus.

A device will typically have a structure similar to this:

Device Communication

A device contains channels that represent the Modbus channels the device offers. The values of these channels can be read and written.

A device’s channels are read using polls. A poll can either be part of the device itself, or, in case of Modbus RTU devices, of the RTU bus the device is on. Channels that are not associated with a poll are not queried.

A device’s output channels are written using a device task named writeOutputs that can be inserted into a Xentara execution pipeline. When this task is executed, all pending write operations are sent to the device. You only need to schedule in a pipeline this task if you intend to write values to output channels.

Reconnecting Devices

If the communication with a device is disrupted, then the Xentara Modbus driver can no longer communicate with it. Once the device becomes available again, the communication channel to the device must be reestablished, so that the communication can be resumed. For Modbus RTU devices, this happens automatically, as long as the serial bus the device resides on remains open. For Modbus TCP devices, however, the TCP connection must be reestablished before communication can resume.

The Xentara Modbus driver does not automatically attempt to reestablish the connection, because this may require DNS lookups, ARP/NDP discovery, or other operations that may produce undesired network traffic. It may therefore be desirable to attempt to reestablish the connection at a greater interval than the normal polling interval. The Xentara Modbus driver therefore allows you to schedule the reconnection attempts of a Modbus TCP device separately from the polling and writing of outputs. Modbus TCP devices have a task named reconnect that must be inserted into a Xentara execution pipeline in order to schedule the reconnection attempts. If you do not schedule this task, then communication with the device will not resume if the device ever goes offline, even if it comes back online.

Accessing Devices

See also

Accessing Xentara Elements in the Xentara user manual Modbus devices have the following members:

Attributes

key	The device’s primary key.
name	The device’s name. The name is the last component of the primary key.
UUID	The unique UUID of the device.
type	The device’s element type. For Modbus devices, this is always “Modbus TCP device” or “Modbus RTU device”.
category	The device’s category. For Modbus devices, this is always “device”.

Tasks

writeOutputs

Send pending write requests to the device.

Modbus TCP Devices

Modbus TCP devices have the following additional members:

Attributes

deviceAddress	The host name or IP address of the device.
devicePort	The TCP port number of the device.

Tasks

reconnect

Attempts to reestablish the connection to the device if it is down.

Modbus RTU Devices

Modbus RTU devices have the following additional members:

Attributes

bus	The serial port device of the RTU bus.
baudRate	The baud rate of the RTU bus, in bits per second.
serverID	The server ID (formerly slave ID) of the device on the bus.