The I/O Component Hierarchy

I/O drivers can determine how the data they expose are organized into I/O devices. The driver may expose all I/O points as a single device, it may group them into several different devices, or it can expose a whole hierarchy of devices.

A driver that serves self-contained physical devices will usually expose one I/O component per device. The Xentara Modbus driver, for example, exposes one I/O component for each Modbus TCP device it services:

Drivers that support devices that are chained together on a bus will usually expose the bus as an I/O component as well, and make the actual devices children of the bus. The Xentara Modbus driver, for example, exposes one I/O component for each Modbus RTU bus it services, and one child I/O component for each actual device:

A driver may also subdivide a single physical device into a number of logical devices. This is usually done if the logical sub devices have their own sub device addresses. The Xentara Comedi driver, for example, is a driver that provides access to I/O boards installed in the local computer using the Linux Comedi framework. The Comedi framework divides each physical device into subdevices containing functionally identical channels. The Xentara Comedi driver mirrors the Comedi framework’s device hierarchy by exposing an I/O component for each Comedi device, and a child I/O component for each Comedi subdevice:

Connection Based I/O Components

Many I/O components are connection based, meaning that Xentara has to establish a connection to the corresponding device in order to communicate with it. This includes most devices connected via network, e.g. using Modbus TCP or OPC UA.

Tracking Connection Status

Connection based I/O devices will often publish an Boolean attribute named “deviceState” that contains the connection status of the device. The attribute will be true if the device is connected and functioning properly, and false otherwise. The device may also have two events named “connected” and “disconnected”, that are triggered when the device is connected and disconnected, respectively.

Please refer to the documentation of the specific device for details on how exactly reconnection status can be tracked.

Reconnecting Devices

If the communication with a device is disrupted, then Xentara 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. Many devices do not do this automatically, but have a task named reconnect that must be inserted into an 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.

Please refer to the documentation of the specific device for details on how exactly reconnection attempts are handled.

Accessing I/O Components

I/O components have at least the following members:

Attributes

key	The I/O component’s primary key.
name	The I/O component’s name. The name is the last component of the primary key.
UUID	The unique UUID of the I/O component.

I/O components can optionally also have the following members:

Optional Attributes

deviceState A Boolean value denoting whether the I/O component is functioning properly. This attribute will be true if the component is operation correctly, and false if there is a problem.

Optional Events

connected	This event is triggered when the connection to a connection based I/O component has been established successfully.
disconnected	This event is triggered when the connection to a connection based I/O component has been lost.

Optional Tasks

reconnect Attempts to reconnect a connection based I/O components if the connection is down.

Each individual type of I/O component can have additional members. Most I/O components will have an attribute containing the device address, for example. Please refer to the documentation of the specific I/O component for details.

To refer to a member, use its primary key. The primary key of the UUID attribute of an I/O component called “My.I/O.Component” is “My.I/O.Component.UUID”.

Table of Contents

The I/O Component Hierarchy

Connection Based I/O Components

Tracking Connection Status

Reconnecting Devices

Accessing I/O Components