IO-Link Changeover: ID Without RFID – Hub ID

When looking at flexible manufacturing, what first comes to mind are the challenges of handling product changeovers. It is more and more common for manufacturers to produce multiple products on the same production line, as well as to perform multiple operations in the same space.

Accomplishing this and making these machines more flexible requires changing machine parts to allow for different stages in the production cycle. These interchangeable parts are all throughout a plant: die changes, tooling changes, fixture changes, end-of-arm tooling, and more.

When swapping out these interchangeable parts it is crucial you can identify what tooling is in place and ensure that it is correct.

ID without RFID

When it comes to identifying assets in manufacturing today, typically the first option companies consider is Radio-Frequency Identification (RFID). Understandably so, as this is a great solution, especially when tooling does not need an electrical connection. It also allows additional information beyond just identification to be read and written on the tag on the asset.

It is more and more common in changeover applications for tooling, fixtures, dies, or end-of-arm tooling to require some sort of electrical connection for power, communication, I/O, etc. If this is the case, using RFID may be redundant, depending on the overall application. Let’s consider identifying these changeable parts without incurring additional costs such as RFID or barcode readers.

Hub ID with IO-Link

In changeover applications that use IO-Link, the most common devices used on the physical tooling are IO-Link hubs. IO-Link system architectures are very customizable, allowing great flexibility to different varieties of tooling when changeover is needed. Using a single IO-Link port on an IO-Link master block, a standard prox cable, and hub(s), there is the capability of up to: 

    • 30 Digital Inputs/Outputs or
    • 14 Digital Inputs/Outputs and Valve Manifold Control or
    • 8 Digital Inputs/Outputs and 4 Analog Voltage/Current Signals or
    • 8 Analog Input Signals (Voltage/Current, Pt Sensor, and Thermocouple)

When using a setup like this, an IO-Link 1.1 hub (or any IO-Link 1.1 device) can store unique identification data. This is done via the Serial Number Parameter and/or Application Specific Tag Parameter. They act as a 16- or 32-byte memory location for customizable alphanumeric information. This allows for tooling to have any name stored within that memory location. For example, Fixture 44, Die 12, Tool 78, EOAT 123, etc. Once there is a connection, the controller can request the identification data from the tool to ensure it is using the correct tool for the upcoming process.

By using IO-Link, there are a plethora of options for changeover tooling design, regardless of various I/O requirements. Also, you can identify your tooling without adding RFID or any other redundant hardware. Even so, in the growing world of Industry 4.0 and the Industrial Internet of Things, is this enough information to be getting from your tooling?

In addition to the diagnostics and parameter setting benefits of IO-Link, there are now hub options with condition monitoring capabilities. These allow for even more information from your tooling and fixtures like:

    • Vibration detection
    • Internal temperature monitoring
    • Voltage and current monitoring
    • Operating hours counter

Flexible manufacturing is no doubt a challenge and there are many more things to consider for die, tooling and fixture changes, and end-of-arm tooling outside of just ID. Thankfully, there are many solutions within the IO-Link toolbox.

For your next changeover, I recommend checking out Non-Contact Inductive Couplers Provide Wiring Advantages, Added Flexibility and Cost Savings Over Industrial Multi-Pin Connectors for a great solution for non-contact connectivity that can work directly with Hub ID.

How IO-Link Sensors With Condition Monitoring Features Work With PLCs

As manufacturers continually look for ways to maximize productivity and eliminate waste, automation sensors are taking on a new role in the plant. Once, sensors were used only to provide detection or measurement data so the PLC could process it and run the machine. Today, sensors with IO-Link measure environmental conditions like temperature, humidity, ambient pressure, vibration, inclination, operating hours, and signal strength. By setting alarm thresholds, it’s possible to program the PLC to use the resulting condition monitoring data to keep machines running smoothly.

Real-time data for real-time response

A sensor with condition monitoring features allows a PLC to use real-time data with the same speed it uses a sensor’s primary process data. This typically requires setting an alarm threshold at the sensor and a response to those alarms at the PLC.

When a vibration threshold is set up on the sensor and vibration occurs, for example, the PLC can alert the machine operator to quickly check the area, or even stop the machine, to look for a product jam, incorrect part, or whatever may be causing the vibration. By reacting to the alarm immediately, workers can reduce product waste and scrap.

Inclination feedback can provide diagnostics in troubleshooting. Suppose a sensor gets bumped and no longer detects its target, for example. The inclination alarm set in the sensor will indicate after a certain degree of movement that the sensor will no longer detect the part. The inclination readout can also help realign the sensor to the correct position.

Detection of other environmental factors, including humidity and higher-than-normal internal temperatures, can also be set, providing feedback on issues such as the unwanted presence of water or the machine running hotter than normal. Knowing these things in real-time can stop the PLC from running, preventing the breakdown of other critical machine components, such as motors and gearboxes.

These alarm bits can come from the sensors individually or combined together inside the sensor. Simple logic, like OR and AND statements, can be set on the sensor in the case of vibration OR inclination OR temperature alarm OR humidity, output a discrete signal to pin 2 of the sensors. Then pin 2 can be fed back through the same sensor cable as a discrete alarm signal to the PLC. A single bit showing when an alarm occurs can alert the operator to look into the alarm condition before running the machine. Otherwise, a simple ladder rung can be added in the PLC to look at a single discrete alarm bit and put the machine into a safe mode if conditions require it.

In a way, the sensor monitors itself for environmental conditions and alerts the PLC when necessary. The PLC does not need to create extra logic to monitor the different variables.

Other critical data points, such as operating hours, boot cycle counters, and current and voltage consumption, can help establish a preventative and predictive maintenance schedule. These data sets are available internally on the sensors and can be read out to help develop maintenance schedules and cut down on surprise downtimes.

Beyond the immediate benefits of the data, it can be analyzed and trended over time to see the best use cases of each. Just as a PLC shouldn’t be monitoring each alarm condition individually, this data must not be gathered in the PLC, as there is typically only a limited amount of memory, and the job of the PLC is to control the machines.

This is where the IT world of high-level supervision of machines and processes comes into play. Part two of my blog will explore how to integrate this sensor data into the IT level for use alongside the PLC.