Figure 2: Structure of the sub-bus tunnel telegram: The tried and tested 'onion skin' model is used here for Ethernet protocols, in which protocol layers are encapsulated within one another.

© Bosch Rexroth

Figure 2 shows the structure of a request telegram (Sub-Bus Tunnel PDU). It can be seen here that both individual and total requests are possible with one protocol sequence (using several Command PDUs). The latter can even be addressed to different participants so that, for example, all electronic type plates can be read out 'in one go'. Sum requests to a single subscriber can also be used to optimize the entire parameterization of the subscriber from a PLC program of the higher-level control system in a single process.

The parameter transfer process is mapped by telegrams (command PDUs). This generalized sub-bus tunnel also applies in principle to other tunnel protocols to be specified, such as AS-i, CAN or Profibus, and thus enables similar implementations on the controllers. Layer 1 therefore contains the telegram structures up to the command SDU (request/confirmation/error). The IO-Link-specific transport part (layer 2 of integration) is based on the Command SDU level. An example of a request telegram is shown in Figure 3.

Figure 3: Device Command Request SDU: The IO-Link parameter to be read/written is selected in the 'Index' and 'Subindex' fields.

© Bosch Rexroth

The parameter data contents are transferred to/from the device within the respective data object data fields of the IO-Link devices. Errors relating to the data transmission of both the IO-Link master and the IO-Link devices are reported via corresponding error code data fields. For device identification, the identification data of all devices is read out during start-up and stored in a separate sercos parameter. This includes the values of the VendorID, the DeviceID and the FunctionID. This enables simple checking, for example by a PLC program.

The master configuration of the IO-Link ports - the so-called port configuration - corresponds to that of a fieldbus. IO-Link has a very lean or simple port configuration, and most of the setting values are handled by the sercos start-up parameterization. Each port can also be reconfigured at runtime using corresponding telegrams. A separate port diagnosis can also be read out for each port, such as the port operating mode, the diagnostic status with status code, the device identification data (VendorID, DeviceID,...), data storage error codes, the IO-Link revision and much more. Last but not least, device diagnostics are available via the familiar sercos diagnostic mechanisms (readable diagnostics, diagnostic memory, error deletion, etc.). The diagnostic codes specified for IO-Link, such as error numbers and diagnostic classes, are mapped 1:1 in sercos. This automatically results in the extension of the diagnostics in the event that new diagnostic codes are specified for IO-Link.

The functions available in IO-Link for device replacement are also mapped: The data storage mechanism of the devices allows all parameter data of a device to be automatically saved in the IO-Link gateway. If a component fails, the user simply has to replace the device with an identical slave. The gateway automatically detects the new participant and carries out the parameterization during the subsequent start-up, whereby no new parameterization of the slave is necessary. Even if the gateway fails, devices can be replaced without reconfiguration: the sercos master can save the configuration of the gateway, automatically detect the device replacement and carry out the new parameterization independently.

Function blocks for the PLC

In the MLC control system from Bosch Rexroth, for example, the following PLC functions are implemented with the help of function blocks (FB):

• acyclical parameter access (IOL_CALL)
• Device identification
• Device diagnostics, port diagnostics
• Command processing
• Port configuration
• Backup/restore of an IO-Link device

The basic function block for reading/writing an IO-Link parameter is shown in Figure 5. This FB uses the aforementioned tunnel protocol for acyclical transmission. Using the backup FB, all parameters of an IO-Link device can be read out and saved on the PLC; the restore FB is used to write the previously saved parameters. These FBs are valuable, for example, if all IO-Link devices of a machine/system are to be parameterized automatically for the first time from a PLC commissioning program of a series machine after it is switched on for the first time. This means that the user is spared the time-consuming manual loading of the parameters into the devices using a commissioning interface or a separate program, for example via a USB adapter. Finally, the diagnostic FB reads the diagnostic information from a device, so the user only has to evaluate the status information (DeviceStatus/StateDetails).

In total, around 15 function blocks are implemented for the integration of IO-Link in sercos.

Example positioning drive

The advantage of sub-bus integration can be illustrated using the example of the PSE3 positioning drive from Halstrup-Walcher, which is available with both Sercos and IO-Link. The drive with Sercos requires three M12 connectors, while IO-Link only requires one M12 connector. This simplifies installation/commissioning. Due to the smaller number of connectors required, the variant with IO-Link is 13% shorter - i.e. 100 mm compared to 115 mm.

Sercos scores points in terms of performance: Sercos allows cycle times of 1 ms compared to 8 ms with IO-Link. This means that although Sercos is faster for setpoint specification or refresh rates of actual or status values, in positioning applications, for which the PSE3 is designed, this will rarely have an effect in practice.

In conclusion, it can be said that The specification for the integration of sub-buses in sercos offers very convenient options. The two-level nature of the specification makes it easy to integrate other sub-buses in addition to IO-Link in the same way; there is little change for the user at the protocol level. Support in control systems benefits from this architecture, as large program parts can be reused for other sub-buses. The basis for this are standard Sercos mechanisms, which every Sercos controller can handle today. Initial implementations are available and are already being used in prototype applications.

Author:
Dr. Stephan Schultze works at Bosch Rexroth in Automation Systems Motion Logic Control Development.