Fieldbus Devices and I/O Drivers

The technical basis for each fieldbus device, which is configured in the device tree, is the I/O driver.

The I/O driver is the link between the fieldbus stack, the IEC application, and the IDE. The driver configures the fieldbus stack from the data of the device configuration. It shows the diagnosis, provides an API for the IEC application, and is responsible for the I/O mapping (see chapter "I/O Mapping").

This chapter provides a brief overview of the basic functionality of I/O driver devices, without discussing the details of specific bus systems. In addition, some recommendations for the configuration are provided.

Bus cycle task

The bus cycle task is the IEC task in whose context the I/O driver is executed. Some I/O drivers use multiple tasks: usually one real-time critical task (with high priority), which is used for the transfer of I/O data, and another task with low priority for tasks such as evaluating diagnostics and executing acyclic services of the bus system.

With real-time critical bus systems, it has to be ensured that no operations are executed in the context of this bus task that would interrupt the bus clock due to the execution time.

The bus task can be configured in the I/O mapping dialog of the I/O driver device. Note that the settings of the parent device are inherited by default. If this device is the PLC, then its PLC setting applies in the bus cycle task.

NOTICE

If this above setting is not set, then the task with the shortest cycle time is used. In this way, a non-real-time I/O driver can be executed unintentionally in the task context of a real-time critical driver, thus interrupting its communication. To diagnose these communication problems, it is recommended to check the task monitoring.

I/O Mapping

An essential function of an I/O driver is to update the I/O mapping. This means the mapping of the I/O data of the bus system to variables of the IEC application (and vice versa).

The input/output data is mapped cyclically by copy and conversion operations in both directions from the internal memory image of the bus system to IEC variables assigned to %I and %Q addresses.

For the I/O driver, there is no internal difference whether symbolic names or "direct" access to the %I and %Q addresses are used for this I/O mapping. For the maintainability of the application, it is recommended to always use descriptive variable names (example: variable "TemperatureReactor" instead of "%IW117" access).

The updating of the I/O mapping can be set with “Always update variables” (globally in the “PLC Settings” or individually for each device in the I/O mapping dialog):

Disabled:

Only I/O data used in the application is mapped.

This may improve performance by avoiding the copy operations, but may cause confusion if the I/O data in the I/O mapping dialog is not updated (the values are then grayed out). This setting is recommended for an application whose development has been completed.
Enabled 1:

All data is updated.
Enabled 2:

IMPORTANT:

The availability of this option depends on the device description.

Caution: For productive use in special cases only.

As a result, inconsistent I/O data may occur, because the bus cycle task reads/writes this data while the application code uses it in other tasks.

Consistency of I/O data

The programming system allows the IEC application to use multiple tasks executed in parallel (for visualization, field buses, or other POUs). The application code can access I/O data from the context of these tasks via the mapped IEC variables. By accessing the same data from different tasks, inconsistent or corrupt data could occur (for example, due to interrupted write access).

The I/O driver ensures data consistency by providing each task executing a task cycle with a consistent mapping – a snapshot, so to speak – of all I/O data used.

So a code like in the following example cannot cause problems: (Note "DIV by ZERO")

IF(inputData <> 0) THEN              // inputData is mapped to %I
    x := y / inputData;              // This will never result in DIV_BY_ZERO Exception
END_IF                               // inputData is not updated by bus cycle during execution of POU

NOTICE

With the “Always update variables” option set to “Enabled 2 – always in bus cycle task”, this mechanism is overridden. Accordingly, the application code has to take this into account.

Services

In addition to the basic functionality, some I/O drivers provide services that can be called from the IDE, such as the device scan function or the setting of device addresses.

General recommendations

Settings:

“PLC Settings”: I/O updates in stop:

The bus cycle continues even when the application is stopped, for example when the application is on a debug breakpoint. In this way, communication with the field devices is maintained and can be continued immediately without interruption.
“PLC Settings”: “Always update variables” is set to “Enabled 1 – use bus cycle task if not used in any task”:

During the development of the application, it is useful to see the values of all I/O data.

Task configuration:

Especially for real-time critical fieldbus systems such as Profinet, EtherCAT, or CAN, which depend on maintaining an exact send/receive clock, it is recommended to use a separate bus cycle task with high priority. For less real-time-critical tasks (for example, visualization) a significantly lower priority should be selected than for the bus cycle task.
In order to achieve maximum I/O throughput with as little offset as possible, separate POUs can be executed in the bus task of the fieldbus system. However, these then have to meet the real-time requirements: for example, no file access or blocking socket functions may be executed, but for example only the calculation of the output data.

Multiple I/O drivers and tasks (troubleshooting)

If consistent access to I/O data from multiple tasks and possibly across multiple I/O driver instances has to be synchronized, then undesired reciprocal interference between the bus and application task may occur under certain circumstances.

This is the case, for example, when the general system load is high or when the I/O data of the real-time critical fieldbus system is used together with I/O data of a slow and blocking local bus system in the same task.

In case of unexpected interference of the communication, with the particularly real-time-critical fieldbuses (EtherCAT, Profinet, CAN), the task monitoring should therefore first be examined for very large jitter or outliers in the cycle time (maximum value compared to average value). The task list provides detailed information about the use of I/O data in different tasks.

It may be possible to avoid using I/O data from different bus systems in one and the same task or to reduce the number of I/O tasks.