We really appreciate how we can use generic software modules in B&R Automation Studio’s LogicalView and map variables to different hardware configurations without impacting the source code of our POUs.
Now, we’d like to incorporate IO-Link sensor/actuator hubs for digital signals using B&R’s X20cDS438A IO-Link Master. Through the IO-Link Master configuration, we can mimic the process data structure of the IO-Link device and perform conventional IO mapping to direct specific parts of the process data into our software modules.
However, we’ve encountered two main limitations:
The number of distinct data fields we can define.
The available data types.
Our IO-Link devices provide two bytes for PDin and two bytes for PDout, where each bit corresponds to a boolean signal at the field level. We’re looking for best practices to extract these individual bits from the process data without pulling “hardware-configuration concerns" into the source code of our standardized POUs.
Here are two approaches we’ve considered so far:
Dedicated Task + PV Mappings
Map the process data to a dedicated task, split it up, and then use PV mappings to route the signals to other modules.
The downside is potential cycle delays and other less-than-ideal side effects.
Mapping entire IO-Link Process Data to Multiple Modules
Map the full PD and use parameters in each module to identify the relevant bits.
This seems to work for inputs, but outputs would still require another layer of hardware abstraction across multiple POUs.
Does anyone have recommendations or best practices on how to handle this bit-level mapping in a clean and efficient way without cluttering the code in our POUs? We’d be grateful for any tips, tricks, or insights you can share!
Thanks for sharing the link, but I’m afraid it only addresses the simpler aspect. Setting a bit in an integer isn’t really the challenge I’m facing.
The example you provided does, however, illustrate my main concerns:
With the octet-array approach you loose the ability to force one of the valves while leaving the others controlled by the software.
The plant or machine’s hardware configuration is effectively hard-coded into the octet array used for the valve terminal. If a future machine has a different valve terminal configuration, the source code itself would need to be updated instead of just the mapping.
From the screenshot, there appears to be a dedicated program for valves called “Festo.” This might act as a hardware abstraction layer, collecting signals from multiple programs and combining them into the octet array that’s sent to the valve terminal. If the signals are mapped to the “Festo” program via variable mappings, one cycle gets dropped—which might not be critical for pneumatic valves, but could lead to unintended behavior in other scenarios.
Unfortunately that’s the tradeoff between specificity and customizability; there are pros and cons to both.
It’s just my opinion, but I think that your first option (Dedicated Task + PV Mappings) would be easier to maintain in the long run. You can map an input to multiple PVs, but as you said mapping an output to multiple sources would be really messy. If you put enough thought into the program/function that packs and unpacks the I/O though you could make something that seems fully customizable to the end user. Maybe you could configure the entire I/O layout from a recipe file or something like that.
Normally I like to keep I/O local so datapoints are only available to one program. That program can then pass along a global status to others if it needs to. However, this may be a good case for a global “gIO” structure that allows access to the unpacked datapoints. The PV mapping is also an option but I personally find it a little cumbersome to use. If you map everything in code, you could access pointers to values which allows for more flexibility.
Thank you for your insights. Since we’re using AppModules, we also keep IOs locally, each with its own *.iom file. We’ll likely move forward with the IO-handling-Task approach you suggested and aim to maintain usability for the commissioning team, who primarily rely on the physical view.
I have actually used IFM IO-Link masters (model AL1122) as well as the B&R X67DS438A. The main drawback with the B&R unit is it can’t handle 32 byte PD. It is only capable of 29 bytes (if I remember correctly). This was a huge problem when using a Banner IO-Link smartlight, as the mode selection was controlled in the 30+ byte range. If you want to check out what I did I would be happy to share a sample program.
I came across your thread about the issue with the Banner LED strip. We encountered a similar problem with a 7-segment display (Captron Caneo) but managed to get it working by using multiplexed Octet Arrays on the DS438A.
I also had the IFM Master on my desk, as we were testing its capabilities with the additional Ethernet port.
Do you know if the IFM Masters can be deployed in a Powerlink ring?
I believe you can, but only with the following part numbers - AL1370 & AL1372. I used the EIP version (AL1122) with an X20IF10D1-1 as an EIP master. I had a bunch of other wireless IO I needed to communicate with using Ubiquiti P2P. I did play around with the Powerlink version in a sample project, but for me, it was not significantly easier than the EIP.
Yes, we had the AL version on site. As for EIP, I believe the new Balluff multi-protocol master is a strong contender. It’s a pity they don’t offer Powerlink. https://www.balluff.com/en-de/products/BNI00K6