I’m currently diving into a project aimed at controlling a Banner LED strip through IO Link. The setup involves configuring an ST program on the PLC to keep an eye on specific values from an HMI and adjust the LED strip accordingly. To meet the LED strip’s 32-byte requirement for control, I’ve opted for a flat stream approach.
Initially, everything runs smoothly, and the PLC effectively controls the LED strip. However, after a while, I hit a snag – an error crops up, hindering LED strip control until I restart the PLC. Here’s a snapshot of the error: Error Screenshot.
Whenever data is written to the LED strip, it is supposed to send a response. By monitoring program values, I can confirm it’s responding every time. I’m puzzled about what additional response it might require, considering the error.
I’ve tried looking for a solution on various forums and the official sites of both Banner and R&B, but haven’t found a fix yet.
Here’s the link to the Banner LED strip I’m using: Banner LED Strip.
If anyone has any insights or suggestions on how to resolve this issue, I’d greatly appreciate it. Thanks in advance!
The way I interpret this message is that there was a timeout when writing the RunMode register to the LED strip device. Based in the information on the manufacturer’s website, it seems that this register is 256 bits (32 bytes) long. It also looks like there are 10 bytes of actual data spread out throughout that 32-byte register. However, it’s odd to me that this message appeared as an Automation Studio popup. It is possible to establish communication to the connected IO-Link devices via Automation Studio for diagnostic, but usually this is done automatically by the PLC and the associated application.
Unfortunately I don’t have a quick answer for you, but since it seems no one else has any ideas at the moment I do have some thoughts/questions that will hopefully help lead us in the right direction:
Which IO-Link Master device are you using?
Are you using the connection functions built into Automation Studio (right-click on the IO-Link Master → Additional functions) or is the communication handled entirely by the PLC?
Are there any devices connected to the IO-Link Master besides the LED banner?
The IO-Link Master has a ChannelStatus for each IO-Link channel in its I/O mapping. What is the value of this status before and after you lose communication?
After you lose communication, is the IO-Link Master still communicating with the PLC (ModuleOk = TRUE)?
Are you using the AsIoLink library to paramterize the LED banner from code, or are you only reading/writing data to/from the I/O mapping of the Master only?
And lastly, have you made any progress since posting this?
I am using the x20DS438A (Rev3) B&R interface with firmware 2.4.2.0.
The communication is handles entirely by the PLC.
There are no other devices connected to theIO-Link Master.
The ChannelStatus value is “4”, this is both before and after the error.
ModuleOk = True
I have code which writes the data to the I/O mapping of the master.
Since posting I have tried the following:
Timing
We have checked and adjusted the timing settings to ensure that the timing of both the PLC and the interface matches.
Power Supply
We have installed a different power supply that can deliver much more power in case this was an issue. This turned out to have no effect. (The LED-strip is connected directly to the power supply)
Fixture
We have used a different Banner LED strip to rule out a defect in the current LED strip.
Software
The code on the PLC has been thoroughly examined for errors that could cause the error.
Interval
The code has been rewritten with intervals as we thought it might be sending too much data in a short time. Even with intervals of 60 seconds, the error still occurs.
IO Link Master
We have replaced the B&R IO Link Master with another one to rule out a defect.
IO Link Master firmware
The latest firmware for the IO Link Master has been installed.
Some noteworthy information:
Initially, when I started controlling this LED-strip, I noticed it required 32 bytes. B&R sent me a tutorial document about using flat stream. In this tutorial, they recommend using the “LibAsFltGen” library, which includes a “Status” variable that automatically updates with an error code in case of an error
This is how the error happens:
1 I start writing to the LED strip, everything is working for about 3 to 4 minutes.
2 The IO Link error light starts double flashing and the LED-strip stops changing its lights. In monitor mode you can see that it is still responding with data when you write to it.
3 If you write 4 or 5 times, the “Status” variable of hte library changes to “33800”
The Pop up in the screenshot only shows up when you are connected to the LED-strip with the connection functions built into Automation Studio when the error happens.
Any insights you might have would be greatly appreciated!
You do need to use the AsFltGen library, and the reason is that you’re sending the device 32 bytes of data. X2X has a limit as to how much data can be transferred to/from each module synchronously and so if you want to output more than 27 bytes of data to your IO-Link device, the data must be multiplexed (sent across multiple X2X cycles). That is what flat stream communication (and the AsFltGen library) does.
A double flash on the X20DS438A indicates some sort of communication error:
But I find it interesting that everything works fine for a time, then suddenly stops. Since ModuleOk remains True, and the ChannelStatus remains as 4 (OPERATE mode, communication is running), it seems that the module and the IO-Link device are still communication with each other, but there is a communication error between the program and the module (error 33800 means that the AsFltGen library lost connection to the module).
This sounds like it could be a timing issue. I know you said that you checked that the timing of both the PLC and the interface matches. I’m assuming this means that your system timer is set to match your X2X interface. A good test would be to put the IO-Link communication program in a cyclic task class that matches this cycle time, and then set the tolerance of that task class to zero. This would rule out any timing discrepancies. I’d also recommend double checking the logger for any related warnings or errors.
Finally, you could try changing the MTU setting. This setting determines how much data is sent per cycle, and therefore how many cycles it takes to send an update. This is a dropdown in the module configuration so you can’t pick any number you want, but there are various options. I think that with 32 bytes of data, an MTU of 19 is the most optimal choice (this ensures that all data is sent in two cycles) but you could try different options to see if this changes your results. Though if you do change this parameter, make sure that txBytesLen on the fltWrite() function block matches the new value!
I delved into the “IO Link reference guide” of the LED strip to seek any cycle time information. According to the documentation, it states “Minimum cycle time = 11.2 ms”.
I transitioned the program from Cyclic #4 (100 ms) to Cyclic #1 (10 ms). Unfortunately, the error persisted. Subsequently, I tested it on Cyclic #2 (20 ms), yet encountered the same issue.
Despite having the MTU setting already at 19, I experimented with other options, but sadly, none resolved the problem.
I added another IO Link device, a sensor, on the IO Link Master to see what would happen. It seems that when the LED strip stops responding, the sensor continues to function. When I keep writing, the errorcode shows up and the sensor stops working as well.
Regarding Banner, I’ve attempted to reach out multiple times via email, but unfortunately, I haven’t received any response.
After doing some more testing I noticed that the error occurs every 24th time I write to the LED-strip. I have to restart the whole PLC for the IO Link to function again. I thought I would share this in case this makes it more clear.
That regularity is really interesting. It doesn’t make things clearer at the moment, but I do wonder why the error is so predictable.
I know that the device’s minimum cycle time is 11.2 ms (this is probably the cycle time requirement between the LED strip and the X20DS438A), but I think that it would still be a good idea to minimize communication delays between the PLC and the X20DS438A. To do this, I recommend these steps:
Match your System Timer to your Powerlink interface (if you’re using a Powerlink bus controller) or to your X2X interface if not. The default cycle time for both Powerlink and X2X is 2ms, and this will force your cyclic task classes to be a multiple of whatever your communication cycle time is. This is done in the CPU configuration:
Set your first cyclic task class to match this time exactly. As long as your CPU is not at high usage, I think it would be a good idea to keep the communication to the IO-Link master running as fast as possible, and as synchronously as possible with the X2X network. 10ms is quite high for the X2X network, so I recommend syncing everything at 2ms if your application allows it:
Then place your flatstream communication program in Cyclic 1. It can be moved later, but I just want to make sure we rule out any timing issues between the program and the X20DS438A
After taking a closer look at the LED strip’s specification, there are a couple of other things that I think could help provide more information, the return data from the device and the IO-Link events.
It looks like the LED strip returns only one datapoint, the Segment Mode. This is a 32-byte value that shows the status of each segment on the strip. How does this behave when the output stops writing correctly? Does the value go to zero or do you continue to receive valid data? Both the Read and Write function blocks have their own error numbers, so it would be interesting if only the Write data was affected.
The other thing which I think could help is IO-Link Events. The LED strip should return error numbers that detail the cause of the error:
These can be read using the ioLinkGetEvent function block in the AsIOLink library. However I think that they can also be read from the Events section of the Device Configuration in Automation Studio as long as you’re connected to the device:
If you lose communication with the device completely, you probably won’t receive any error information. However I’m hoping that an error gets sent immediately before the device disconnects.
Unfortunately it looks like no one else has any ideas they can respond with. I’m happy to keep helping you as best I can here, but it may be worth reaching out to your local B&R support team to see if they can give you more direct support.
I wanted to follow up with you regarding the changes we implemented based on your suggestions. Unfortunately, it seems that adjusting the settings did not yield any changes in the behavior of the LED strip.
When the error lights starts flashing the LED strip keeps responding with data up until the point where errorcode 33800 comes up. At that point it does not respond anymore.
The thing I realise is that the strip responds with 1 byte when I write to it, maybe it is because I am using RUN mode instead of Segment Mode. I will take another look at what the responses need to look like.
The value of this byte keeps changing when I write to the LED strip:
While connected to the LED strip the following can be seen:
I reached out to B&R again, providing them with a copy of my project and the new information about the error. Their response was that they too are unable to identify the cause of this error.
I want to express my sincere gratitude for your help and your time throughout this troubleshooting process.
You’re welcome, I’m happy to help where I can! Unfortunately it sounds like this is a tricky one. I think you’re on the right track with understanding what the responses from the LED strip are supposed to be, and with changing modes to see if the behavior differs.
In my last reply, I mentioned reading back the only datapoint that the strip returns. However I think I misread the datasheet before I typed that. Looking again, it looks like no data is actually returned:
I wonder what that byte you’re getting is for. It might just be the control byte used by the AsFltGen library if there’s no data being received.
The Events screen is also not as helpful as I would have hoped. It shows what you said - the connection works and communication is active for a few minutes. Then the connection is lost and cannot be re-established.
My only idea at this point is to gather as much data as possible to see if there’s anything in that data which helps make sense of the situation. I’m surprised there are no event codes showing up in your screenshot, but perhaps there is another way to see the device’s event codes. You can enable these to show up in the I/O Mapping using the module’s Configuration. There’s also a setting related to the IO-Link cycle time. Perhaps changing this might yield a different result:
If there is an event code, it’s possible that it will change quickly, so you might want to copy this value into another variable when it changes from the default, even for one cycle.
Another thought I just had is that this could be related to interference between the PLC, the I/O module, and the LED strip. What does your hardware layout look like? I’m assuming PLC → PLK Bus Controller → I/O module. Is that correct? If so, the Powerlink and X2X networks have some diagnostic datapoints that can be used to check for communication issues (see: Helpful I/O Datapoints for Machine Diagnostics).
Of course if communication all the way to the X20DS438A is okay, there could also be some noise between it and the LED strip. Does the error occur after 3-4 minutes no matter what, or does it only occur if the machine is run during that time? Do the communication wires pass by any high voltage (e.g. motor) cables? Is there any way you could set this device up on a test bench or in a different location to verify that the issue isn’t related to some external factor?
The set up looks like this:
PLC → IO Link Master → Banner LED
(X20CP1584) (X2X) (X20DS438A) (IO Link)
I have monitored the datapoints for Machine Diagnostics, the moment the plc starts up this is what the values look like:
While writing to the LED strip, these values do not change, and when the error comes up the values also remain the same.
It’s important to note that my setup has been stationary on my desk throughout this troubleshooting process, and there’s no exposure to high voltage nearby. Additionally, the error does not consistently manifest after 3 or 4 minutes of operation, but rather occurs consistently every 24th time I attempt to write to the LED-strip.
For clarity, here are two scenarios to illustrate:
Scenario #1:
1. I write 20 times to the light, nothing happens.
2. I wait 3 hours, nothing happens.
3. I write 4 more times, the error pops up.
Scenario #2:
1. I write 24 times to the light, the error pops up.
I hope this additional information provides more insight into the issue at hand.
I recommend watching the FlatStream sequence bytes (likely RxBytes[0] and TxBytes[0]) as you reach your error condition. These bytes handle the synchronization between the PLC and the DS438A and are the best diagnostics for error 33800. You will want to look at them in binary format (right-click, Format > Binary).
In short, the low nibble (4-bits, one hex character, or half a byte) of the Input Sequence should be mirrored by the high nibble of the Output Sequence, and vice versa (low nibble of Output is mirrored by the high nibble of Input).
The highest bit in each nibble (bits 3/7) indicate a valid synchronization. The other 3 bits are a sequence counter to keep track of when new information is available (increment when new information is placed in iomapping, increment to acknowledge that information has been received).
If the sync bit goes low, then that indicates that there was some disagreement between the PLC and DS438A about where the communication was. I think this is reflected in a screenshot on your May 1st post. Ex. 209 on the input sequence breaks down to: 1101_0001.
High nibble (Output ack): 1101 => sync is good, and the sequence is at #b101. If this matched the low nibble of the output sequence, everything is good.
Low nibble (Input sync): 0001 => not synchronized, and the sequence number has been reset to #b000. This could be that the input ack (high nibble Output Sequence) went wrong, or the module lost the input ack from the PLC.
To eliminate it as a possibility, you need to ensure your IO-Link cycle time is longer than 11.2 ms. The cycle time of the IO-Link is not necessarily tied with the task class cycle time but is a configuration parameter of the IO-Link interface channel. I recommend changing the mode to X2X synchronized (manual) and running a Cycle multiple of the lowest multiple number of your X2X cycle time, that is above 11.2ms. This may help with the disconnect events in the DTM.
Ex. X2X cycle time is 2ms, set Cycle multiple to 6. Math: 2ms * 6 = 12ms, which is the lowest multiple above 11.2ms.
I am sorry it took so long for me to respond. After my last message I contacted B&R support in the Netherlands again and they asked me to send them the LED strip I have been trying to use. B&R support needed time to runt their own tests and contact other parties to figure out what was going on.
I was in contact with B&R in the Netherlands and they also had a hard time to solve the problem. After contacting the R&D department in Austria they figured out that there was something wrong with the library in Automation Studio. They ran some tests with another library and it worked without any issues.
I would like to thank everyone for their help and their time!
While looking for some information on how I can set up my Banner RGB Strip I came across your thread. I was wondering if you could show/explain how your messages (changing color, animation, intensity, etc…) are sent to IO Link Master, I’m quite new to all this, and any help would really be appreciated.
Of course! Since I have multiple people who asked the same question I will share it here for everyone to find.
This program is the version I received from B&R and I did not change anything to it.: DS438A_examples.zip (231.4 KB)
I also have a document that is supposed to guide the reader through how to use the ASFltGen library with Banner. As you might have read it gave me some issues, but maybe it could give you some insight on how flatstream works. I will add it in case you can use it!
I’ve managed to establish communications with my banner lights using flat stream communication, but I appear to be receiving this error after sending a first message:
33800:
Error constant
fltERR_SYNC
Short text
Connection to electronic module lost in send/receive direction.
Error description
Synchronization of send/receive path was lost.
Suggestion for error correction
Check hardware layout, cabling and I/O configuration.
Did you encounter anything like this? If so what did you do or if anyone has suggestions on what to try please feel free to suggest.
Hi Walid el Oufi.
I believe I am having the same issue as you but I am writing to two lights and it happens every 12 write cycles (meaning its 24/(# of channels written to). I am using the LibASFltGen2_ST library (I am assuming the library that was created because of your error). Do you know what B&R Changed in order for this to function? I would greatly appreciate any help as I am in a time crunch and this is the only error left. Thank you!
