IOLink Command Bugginess

Hi all,

Apologies in advance for the awful title. I don't really know how to succinctly describe my issue.

The platform is AB L320ERS2 v32 communicating to a GEA TA15 IOLink single solenoid on-off valve (with open and closed feedback) over an IFM AL1123 8-port Ethernet IOLink master.

I know what bit in the output data array to toggle high to send a command to the valve to open. When I delete my valve AOI and IOLink mapping AOI and manually toggle the bit from the controller tags, the valve opens just fine (for our discussion, the bit I am toggling is IOLink5:O1.Data[39].8).

However, when I programmatically set the that bit high with an OTE, the valve only opens when I toggle a different bit in the IOLink5:O1.Data[39] INT. It does not matter which other bit I toggle. This behavior is exhibited when trying to open and when trying to close the valve.

I have looked for duplicate destructives for my valve AOI, for my IOLink mapping AOI, and for IOLink5:O1.Data[39] (as well as all other INTs that should be assigned to port 2 of the IOLink master). I have also set OTLs on the command bit being low both before and after the OTE and neither are latched high.

I have successfully set up identical valves in separate but identical system (same IOLink master, same PLC, same valve tops, same firmwares, etc.) and never have I seen this behavior.

This is happening with 3 valves, all on this same IOLink master.

Thanks all, in advance.

I tried a factory reset as well as applying the config from an IOLink master as well as a valve that function fine, and neither fixed my issue.

Well, that's weird.

To re-state the issue: the valve that should be controlled by IOLink5:O1.Data[39].8 correctly changes state when you directly set that bit in the module-defined Output assembly tag.

But when you use your valve AOI and your IOLink AOI to programmatically set the logic that result in IOLink5:O1.Data[39].8 being set, then the actual valve doesn't turn on unless you *also* change the state of logic in those AOIs that sets other output bits in the same [39] element.

You have troubleshot that and found that [39].8 is not apparently ever being set =1 by the logic (you put in latching traps) yet somehow it sometimes does turn on, when OTHER bits in that Word are commanded to change state.

You conclude that there can't be an error in your AOIs because they work correctly on other machines and have not been modified.

Obviously if I were troubleshooting this I would audit and validate the AOI logic I was using.

And then I'd haul out the Wireshark and see what bits are changing in the Output assembly data that's headed out to those IOLink masters.

The fact that the latches don't seem to trap that output tag bit turning on sure does suggest the problem is in the user logic and not in the EtherNet/IP subsystem or the IOLink bridge.

Is this logic something you can ZIP and post ?

We have had this issue and found that the aoi can be different between units.
we has one unit that was firmware 1.5 for example and another unit with firmware 2.0. the 2.0 aoi will not work correctly with the 1.5 version.
i think we disabled the exact match bit in the config section in order for it to work. i hope this helps.
james

Sorry all for going AWOL. I gave up and am going to call IFM this morning.

However, I am still interested in keeping this discussion open in case they can't help me.

Ken, you are close your interpretation. However, I think I had a small brainfart when writing my original post. Even when I toggle IOLink5:O1.Data[39].8 in the tag list with no logic referencing it I still have to toggle something else to get the valve to actuate.

The AOI is extraordinarily simple. It's the existing logic from the plant just stuck in an AOI. Considering I am seeing the same behavior when I just did an XIC(testbit)---OTE(IOLink5:O1.Data[39].8) with all relevant AOIs deleted, I think we can safely say the AOI is not the problem.

Lastly, my OTL traps were to catch the output bit being something other than I wanted. For example, I set IOLink5:O1.Data[39].8 high with an OTE, and before and after the OTE I OTL testbits on XIO(IOLink5:O1.Data[39].8). Same thing in reverse for setting IOLink5:O1.Data[39].8 low. From what I can tell, IOLink5:O1.Data[39].8 never swaps state unexpectedly.

IOLink5:O1.Data[39].8 is truly on when I tell it to turn on with the AOI (also performed OTL tests). There is no doubt of that, in my opinion (and I am obviously never wrong ). I see it in the tag list, I see my OTL traps not showing any weird results, and I see no duplicate destructives. It's just the valve does not actuate (i.e. receive the signal from IOLink5:O1.Data[39].8) until I manually toggle in the tag list some other bit of IOLink5:O1.Data[39]. It does not matter how I set IOLink5:O1.Data[39].8.

I will call IFM and update if I get any progress. If anyone has any suggestions, I am all ears.

Thanks all.

James Mcquade said:

We have had this issue and found that the aoi can be different between units.
we has one unit that was firmware 1.5 for example and another unit with firmware 2.0. the 2.0 aoi will not work correctly with the 1.5 version.
i think we disabled the exact match bit in the config section in order for it to work. i hope this helps.
james

Click to expand...

James,

Where can I find this exact match bit? Attached are 3 screenshots - 2 of LR Device for all IOLink master settings (port-specific settings not included) and the config for the master in my PLC.

Are you talking about about in the PLC module definition, exact match vs. compatible module? If so, I already have it set to compatible module.

Thanks.

Got it figured out (sort of, I guess). I am not certain on the cause of the issue (some sort of corruption?), but creating a new PLC program and exporting/importing all modules and programs solved it.

Just for S&G I tried exporting the working logic and modules to the original program, and it did not work.

All of this was very strange indeed. If anyone has a suggestion as to what may have happened I am all ears, but for now I am satisfied with corruption being the answer.