I/O Components

Table of Contents

• The I/O Component Hierarchy
• Connection Based I/O Components
  • Tracking Connection Status
  • Reconnecting Devices
• Accessing I/O Components

I/O components represent the different physical or virtual components that make up the infrastructure that a southbound skill communicates with. I/O compoennst generally represent one of three types of components:

• Physical or virtual devices, like an EtherCAT controller.
• Sub devices or other logical units within a device, like individual clamps on a controller, or Data Blocks in a PLC.
• Communication busses that can contain several devices, like a serial bus used for Modbus RTU.

The I/O Component Hierarchy

Different skill use different strategies for organizing the I/O components. Some skills use a flat hierarchy, where every I/O components is completely independent of every other I/O components. Some skills organize their components into a hierarchy, where some components are children of other components.

A skill that serves self-contained physical devices will usually use one free-standing skill element per device. The Xentara Modbus driver, for example, uses one Xentara element for each Modbus TCP device it services:

Skills whose devices are chained together on a communications bus will usually expose the bus as one type of element, and make the devices children of the bus element. The Xentara Modbus driver, for example, uses one Xentara element for each Modbus RTU bus it services, and one child element for each individual device on the bus:

A skill 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 skill 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 using one element for each Comedi device, and a child element 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 a 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 element for details on how exactly connection 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 element for details on how exactly reconnection attempts are handled.

Accessing I/O Components

In addition to the standard attributes that all Xentara elements expose, 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 its address, for example. Please refer to the documentation of the specific element for details.