QUESTION:
How can IO-Link® device microcontrollers overcome the challenges associated with adhering to the timing requirements specified in the IO-Link standard?
Answer:
An IO-link device microcontroller is expected to perform multiple tasks simultaneously, which can cause difficulty in responding to a request within the acceptable specified time window. This is especially true if performing a task from which the microcontroller cannot be interrupted. A typical solution for this timing challenge is to use a second microcontroller to manage the IO-Link stack, thereby maintaining a more constant response time interval between the IO-Link device and the IO-Link master. However, this is a highly inefficient approach because it uses more power and requires a much larger PCB and therefore a larger sensor enclosure. A superior alternative is to use a transceiver capable of managing both the data link and physical layers in the communication pathway. By unburdening this task from the device microcontroller, this transceiver enables the design of even smaller, more complex, higher functioning, and cost-effective industrial field instruments.
Introduction
“To do two things at once is to do nothing”—while this take on multitasking by the Latin writer Publilius Syrus might be extreme, there are some circumstances where multitasking can lead to tasks not being performed in the way they were initially intended or on time. As industrial processes become more complex, field instruments like sensors and actuators have evolved to perform several different tasks simultaneously, including maintaining regular communication with a process controller. This imposes additional overhead on the device microcontroller that must be carefully managed or process data can be lost, leading to production downtime (the very thing that modern industrial communication protocols are supposed to reduce).
IO-Link Timing
IO-Link is a 24 V, 3-wire industrial communications standard that enables point-to-point communication between industrial devices and an IO-Link master that, in turn, communicates with higher level process control networks.
In IO-Link applications, a transceiver acts as the physical layer interface between a microcontroller running a data link layer protocol (stack) and the 24 V IO-Link signal line. IO-Link communication involves several types of transmission, including process data, value status, device data, and events. These allow industrial devices to be quickly identified, traced, and attended to if an error occurs, helping to reduce downtime. IO-Link enables remote configuration; for example, if the threshold for a process alarm to be triggered needs adjusting, this can be done by sending the updated threshold to the device over the IO-Link connection without the need for a technician to visit the factory floor.
Communication between an IO-Link master port and a device is subject to several timing constraints and takes place in a fixed schedule called M-sequence time. An M-sequence message includes a command or request sent from the IO-Link master to a device and the reply message from the device. Figure 2 illustrates the timing parameters in an M-sequence consisting of a message between an IO-Link master port and a device message. The device must respond to the master within the response time of the device, tA, which ranges from 1 Tbit to 10 Tbit (Tbit = bit times). For a COM3 baud rate, tA should be between 4.3 μs and 43 μs. If the response time is outside of this range, a communications failure occurs.
When Punctuality Slips
An IO-link device microcontroller is expected to perform multiple tasks simultaneously, which can cause difficulty in responding to a request within the acceptable time window specified for tA. This is especially true if performing a task from which it cannot be interrupted—this type of task is often referred to as a nonmaskable interrupt (NMI). If the device microcontroller does not respond within the specified time window, communication breaks down and must be reinitiated.
For example, in the case of an ultrasonic distance sensor, some of the many tasks that the microcontroller is expected to perform include:
- Send ultrasonic bursts
- Process the intrinsic line from the last burst, then calculate the distance
- Measure ambient temperature to compensate for the speed of sound
- Manage sensor background tasks (for example, power management)
- Reply to IO-Link cyclic requests
- Reply to IO-Link acyclic requests
Continuously processing data samples leaves little time for a microcontroller to manage the data link layer communication tasks, leading to considerable variations in the device response time. In extreme cases, it may not be possible to meet the timing requirement for tA.
Timing issues caused by NMIs cannot be addressed by simply using a faster microcontroller with more features. A typical solution for this timing problem is to use a second microcontroller to manage the IO-Link stack, thereby maintaining a more constant response time interval between the device and the IO-Link master. However, this is a highly inefficient approach because it uses more power and requires a much larger PCB and therefore a larger sensor enclosure.
Managing the Data Link
A superior alternative is to use a transceiver to manage both the data link and physical layers in the communication pathway. The MAX22516 IO-Link state machine (Figure 3) integrates all the functionality commonly found in IO-Link device transceivers, including the 24 V C/Q, an integrated step-down DC-to-DC converter, and 5 V and 3.3 V linear regulators.
This device is the first transceiver to include a full-feature state machine to fully manage the timing of IO-Link data communication. It autonomously handles communication with the IO-Link master for requests such as configuration and maintenance requests, as well as process data transfers using data written to registers and FIFOs by the microcontroller. A major benefit of using this transceiver is that it affords more options when selecting a microcontroller for the sensor, because the device microcontroller is not required to manage the task of communicating with the IO-Link master.
The MAX22516 monitors incoming messages from the IO-Link master. Once a complete indexed service data unit (ISDU) configuration or maintenance request is received, it automatically sends ISDU BUSY messages to the IO-Link master and notifies the device microcontroller that communication has been successfully completed. The microcontroller can load on-demand data into the ISDU FIFO, a task that typically requires many cycles to perform, as time permits. Input process data (PDIn) and output process data (PDOut) are managed by the transceiver using data in the PDIn and PDOut FIFOs, allowing the microcontroller to write data to the PDIn FIFO and read from the PDOut FIFO without any time constraints. Integrated buffers ensure that data in the FIFOs is not lost or overwritten before being processed.
Figure 4 shows how using this transceiver dramatically reduces the time it takes for a device to respond to an IO-Link master compared to an application using a single microcontroller. The device response time is reduced by more than 50%, while the variability is also reduced considerably from 12 μs to 0.25 μs.
The MAXREFDES281 IO-Link device reference design (Figure 5) features the MAX22516 and can be used to verify the timing performance of different types of IO-Link sensors.
Conclusion
The requirement for microcontrollers to manage multiple tasks simultaneously means they sometimes struggle to meet the timing specifications for IO-Link data communications. Some equipment manufacturers are left with the unpalatable alternative of using a second microcontroller to manage the IO-Link stack. This two-microcontroller approach is now no longer necessary because the MAX22516 IO-Link transceiver integrates a state machine that can manage all IO-Link communication, freeing up the main device microcontroller to perform other time-critical tasks.