Posted on

IO-Link Event Data: How Sensors Tell You How They’re Doing

I have been working with IO-Link for more than 10 years, so I’ve heard lots of questions about how it works. One line of questions I hear from customers is about the operating condition of sensors. “I wish I knew when the IO-Link device loses output power,” or, “I wish my IO-Link photoelectric sensor would let me know when the lens is dirty.” The good news is that it does give you this information by sending Event Data. That’s a type of data that is usually not a focus of users, although it is available in JSON format from the REST API.

There are three types of IO-Link data:

      • Process Data – updated cyclically, it’s important to users because it contains the data for use in the running application, like I/O change of states or measurement values like temperature and position, etc.
      • Parameter Data – updated acyclically, it’s important to users because it’s the mechanism to read and write parameter values like setpoints, thresholds, and configuration settings to the sensor, and for reading non-time critical values like operating hours, etc.
      • Event Data – updated acyclically, it’s important to users because it provides immediate updates on device conditions.

Let’s dig deeper into Event Data. An Event is a status update from the IO-Link device when a condition is out of its normal range. The Event is labeled as a Warning or Error based on the severity of the condition change.

When an Event occurs on the IO-Link device, the device sets the Event Flag bit in the outgoing data packet to the IO-Link Master. The Master receives the Event Flag and then queries the IO-Link device for the Event information.

It is important to note that this is a one-time data message. The IO-Link device only sends the Event Flag at the moment the condition is out of range, and then again when the condition is back in range.

Event Data Types, Modes, and Codes

Event Data has three following three components:

      • Event Type – categorized in three ways
        • Notification – a simple event update; nothing is abnormal with the IO-Link device
        • Warning – a condition is out of range and risks damaging the IO-Link device
        • Error – a condition is out of range and is affecting the device negatively to the point that it may not function as expected
      • Event Mode – categorized in three ways
        • Event notice – usually associated with Event Type notifications, message will not be updated
        • Event appears – the condition is now out of range
        • Event disappears – the condition is now back in range
      • Event Code
        • A two-byte Hex code that represents the condition that is out of range

IO-Link condition monitoring sensor

To bring all these components together, let’s look at a photoelectric IO-Link sensor with internal condition monitoring functions and see what Events are available for it in this device manual screenshot. This device has Events for temperature (both warning and error), voltage, inclination (sensor angle is out of range), vibration, and signal quality (dirty lens).

By monitoring these events, you have a better feel for the conditions of your IO-Link device. Along with helping you identify immediate problems, this can help you in planning preventive and planned maintenance.

An IO-Link condition monitoring sensor uses Event Data similarly to report when conditions exceed the thresholds that you have set. For example, when the vibration level exceeds the threshold value, the IO-Link device sends the Warning event flag and the IO-Link Master queries for the event data. The event data consists of an Event Type, an Event Mode, and an Event Code that represents the specific alarm condition that is out of range. Remember this is a one-time action; the IO-Link sensor will not report this again until the value is in an acceptable range.

When the vibration level is back in range, the alarm condition is no longer present in the IO-Link device, the process repeats itself. In this case the Event Type and Event Code will be the same. The only change is that the Event Mode will report Event Disappears.

Within the IO-Link Specification there is a list of defined Event Codes that are common across all vendors. There is also a block of undefined Event Code values that allow vendors to create Event Codes that are unique to their specific device.

“I wish the IO-Link device would let me know….” In the end, the device might be telling you what you want to know, especially if the device has condition monitoring functions built into it. If you want to know more about condition monitoring in your IO-Link devices, check out the Event section in the vendor’s manuals so you can learn how to use this information.

Posted on

What data can IO-Link provide?

As an application engineer, one of the most frequent questions I get asked by the customers is “What is IO-Link and what data does it contain?”.

Well, IO-Link is the first worldwide accepted sensor communication protocol to be adopted as an international standard IEC61131-9. It is an open standard, and not proprietary to one manufacturer. It uses bi-directional, single line serial communications to transfer data between the machine controller and sensors/actuators. No other communication protocol is manufacturer and fieldbus independent, and yet provides this level of communication down to the sensor/actuator level. It provides the user with three different data types: process data, parameter data, and diagnostics or event data.

Process Data

Process data of an IO-Link smart device is considered the latest state of that device. Containing both input and output data, process data is cyclically exchanged between IO-Link master and IO-Link slave device (i.e. sensor or actuator). The time interval or data update rate solely depends on amount of data, 1 to 32 bytes, and speed at which an IO-Link slave device communicates. IO-Link standard (IEC61131-9) defines three different communications speeds; COM1 is set to 4.8kBaud (slowest), COM2 is set to 38.4kBaud and COM3 is set to 230.4kBaud (fastest). Depending on the device, process data may contain status of inputs or outputs of remote I/O hub, position feedback of linear transducers, pressure feedback from pressure transducers, information from am RFID (Radio Frequency Identification) reader, and so on. For more information about process data content, refresh rate, and data mapping, one should reference an IO-Link slave device datasheet or user manual.

Lastly, process data is then buffered in memory of the IO-Link master device and passed to the controller via a specific fieldbus at request packet interval. Request packet interval is set in the controller settings.

Process Data

Parameter Data

Parameter data contains information and parameters specific to the IO-Link slave device. This data is exchanged acyclically, which means that it is requested from the IO-Link master or controller and not time based. Parameters can be read from a specific device or written to. Parameter data is primarily used for device configuration, or verification. A key advantage of IO-Link is that it gives the controller the full access to IO-Link slave device parameters, down to a sensor/actuator level. This means that your controller, PLC or PC based, can change the configuration of an IO-Link’s slave device dynamically without taking the device off line, and without use of proprietary cabling or configuration software.

Typical use of parameter data is for automatic machine configuration, recipe change, process tuning, maintenance, and easy component replacement.

Parameter Data

Diagnostics or Event Data

Diagnostic data provides the controller with events that affect the operation and performance of the IO-Link smart device. Content can vary depending on the device used, and the manufacturer. IO-Link smart devices can provide crucial data such as load, temperature, stress level, overload and short circuit diagnostics, error codes, configuration or parameter issues, access issues, etc., as part of diagnostic or event data. The event code size is 2 bytes, and in hexadecimal data format. This information can then be interpreted by the controller/user using a lookup table or IODD (I/O Device Description) file. User manual will have diagnostic data table that can be used as a reference.

Diagnostic and Event Data

Conclusion

In conclusion, IO-Link enables a plug-and-play relationship between the controller and the devices on the machine. Using IO-Link data, the controller can automatically recognize and configure an IO-Link slave device that is connected to its network. Process and diagnostic data provide continuous feedback on machine status and health down to a sensor level — the lowest level of the automation pyramid.

Keep in mind that the content of process data is specific to the device and will vary from device to device, and manufacturer to manufacturer. This makes IO-Link data one of the main differentiators between smart devices and their manufacturers. Luckily, IO-Link is an open standard, and fieldbus and manufacturer independent, so you can mix and match devices best suited for your application without worrying about device compatibility, special cabling, or third-party configuration software packages.

automation pyramid

 

Posted on

RFID for Work in Process (WIP) – Empowering people to make complex business decisions.

traceability_1From the concrete of the production floor to the carpet in the executive offices, RFID technology provides actionable data which allows organizations to make complex business decisions. Making decisions based on actual data opposed to “best guess” data…I don’t even need to explain that. The trick is collecting that data and making it available for the organization. That is where RFID comes into play.

Work in Process is one of many applications within a plant in which RFID improves overall process efficiency. It helps to enable flexible manufacturing, tracks the work process, and helps to maintain regulatory compliance. Simply put, RFID technology is responsible for collecting the data, but it is up to the humans to use the data.

What is the data that is being recorded and collected?

  • Build Data: What are we trying to build? (for flexible MFG)
  • Process Data: How well did we build it? (Error Proofing or Poka Yoke)
  • Lineage Data: Where did the parts come from? (Tracking sub-assemblies and parts to their origin)

How does this data benefit the manufacturing organization?

Build Data:  Consider a company who is manufacturing seats for an automobile. The number of options on seats today is mind boggling. A few options include: Heaters, automated controls, weight sensors, specialized foam, specialized covers, etc.  The problem is they all look the same to the human eye. When tagged with an RFID tag all that data is written to the memory in the beginning of the process and then the data is read at every work station along the line to identify exactly what needs to be done based on what the finished product is going to be. In the old days, the operator at each station would have to read through a couple reams of paper to determine what needs to be completed. Now an automatic data transfer informs the operator what needs to be completed.

Process Data: At the same seat manufacturer, let’s say there are twenty stations (processes) that a seat must go through in order to be completed. Now, let’s say there was an error installing the heating mechanism in station three. The seat then proceeds through the remaining seventeen stations getting many other things added to it along the way. Then, prior to shipping, it goes through final inspection and the heater problem is identified. Now, that final seat needs to be either scrapped or needs to go back through the rework line. That’s what used to happen in the old days. Nowadays there are error checks in between each station that quickly identify problems immediately opposed to waiting until the end of the line resulting in lost labor and time. As the seat moves from station three to four the error check occurs and either a go or no-go is written to the tag. If the reader in station four reads a no-go off the tag the operator is notified immediately and the production error can be corrected immediately without having to tear the seat apart to fix the problem. Additionally, the entire production process is written to the tag along the way and at the end of the line the information is uploaded to a database.  The tag can then be erased and written to all over again.

Let’s say the seat manufacturer receives a special order that has to be run ASAP. All twenty seats currently on the line need to be removed to make way for the special order. After the special order is completed it’s now time to put the seats back in their respective stations. RFID takes the guess work out of that process because now they can just read the RFID tag and it will tell them the exact station it belongs in.

Lineage Data:  All those seat variations mean many different components coming from many different suppliers. RFID is used to track those parts back to their origin in case of recall or repetitive part failure. Now instead of bringing the entire assembly back and scrapping the seat they can identify the faulty component, replace it, and hold their suppliers accountable to their quality promise.

Ultimately, from the concrete to the carpet, RFID helps manufacturing organizations make high quality products, eliminate un-planned down time, and improve overall efficiency. By allowing operators and executives to make decisions based on actual data, RFID is helping drive manufacturing organizations to the next level.

For more information on RFID solutions visit balluff.us/rfid.