I read this post with great interest and would like to add a few more questions, as you are obviously very familiar with IO-Link.
Do you have any concerns or a solution when an IO-Link participant is replaced? What happens if the firmware version is not the same? Is a PLC update necessary? Or is it possible to transfer the firmware version from the PLC to the device? I think it should be possible for the customer to replace their broken LED lamp after 5 years without any major problems.
Would you mind starting a new thread with your question? This will help make your issue more visible to the community and increase the likelihood of getting expert insights.
I think that IO-Link devices would follow the same general guidelines for replacement as other devices.
Assuming you’re using a B&R IO-Link master, the LED lamp has been added to and configured in the Automation Studio project and transferred to the PLC. This is how the IO-Link master knows how to configure and communicate with the LED lamp.
If the new lamp communicates in the exact same way as the old one, then no PLC update should be needed. However, if the new lamp as different data registers, then you’ll need to update the project with the new communication structure and re-transfer.
When replacing IO-Link devices, it’s a good idea to familiarize yourself with the documentation related to the parameter server and thoroughly review the configuration settings of the master for the validation checks of Vendor IDs, Device IDs etc. These settings enable you to control how your master behaves during device replacement, ensuring a smoother transition. Most of the master functionality is defined by the IO-Link specification, meaning that masters from different vendors generally provide similar capabilities. Consequently the documentation for the X20(c)DS438A is a good read whether you use it or not.
I once came across newer revisions of IO-Link devices that include a “Legacy Mode.” This feature enabled backward compatibility with previous product versions (e.g., V1.0 IO-Link devices), though it comes at the cost of losing access to new features. Unfortunately, I can’t recall the specific type of device that offered this functionality.
If you’re planning to use the parameter server for automatic parameterization when replacing devices, I highly recommend performing thorough testing beforehand. This will help you verify the functionality and better understand how your devices behave in real-world scenarios. While IO-Link technology has improved significantly in recent years, unexpected behavior was not uncommon in the past, especially when dealing with more advanced features such as asynchronous reads, events, and complex parameter configurations. Taking the time to test will save you from surprises down the line.
Thanks for the tip, I have to admit I haven’t looked at the Parameter Server option yet, but that actually looks like exactly what I’m missing. Thanks for the quick reply!
For the sake of completeness, I wanted to share an example where you can configure an IO-Link device to emulate a previous product version without the need for modifications in the PLC software.
For instance, the Sensor/Aktor-Hub Balluff BNI00F7 can be configured to function like its obsolete predecessors, the BNI00AP or BNI00AR.
