We are doing some testing before migrating to 7.3.1 and we have exported a bunch of tags from our 7.2.8 system and imported into a test 7.3.1 system. A lot of our tags seem to be coming back as STALE. I believe all of these tags are Bridging to ControlNet using the PLC5 driver.
Initially we had the green ? tag symbol, but after restarting the gateway we have red outline tags. We have tried restarting the Gateway, the OPC-UA, and the Allen Bradley Drivers modules. We had seen similar issues in the past and usually a restart fixed the problem, but doesn’t seem to now.
The issue seems to be with the the OPC path composition. The tags that have issues in 7.3.1 are using the File/Bit (B3/89) notation which worked in 7.2.8. If we change a stale tag to file:word/bit (B3:5/9) notation it seems to be fine in 7.3.1. Tags with leading zeros in the address are also Stale (B3:00/6 works in 7.2.8 but only B3:0/6 works in 7.3.1).
Has the acceptable addressing changed? Is there something else to reset and reinitialize, or do we have to convert our addressing?
FYI- this has been fixed for 7.3.2 (scheduled to be released the week of Nov 28th). You can also download the latest 7.3.2 beta now if you don’t want to wait for the final release.
I tested the latest 7.3.2-beta4 (b522) and it seems like the shorthand bit notation only works for the first word. Using the PLC5 driver I see B21/15 works, but B21/16 and above does not. Also, previous versions had the ability to read an input address at the word level, such as I:015. This hasn’t worked since 7.3 and still does not in this version.
Can you confirm that the Allen-Bradley Drivers module in your gateway is 1.3.2-beta4 (b146)? The /16 issue was supposed to be fixed in that version. I tested the PLC5 driver using that Allen-Bradley module and this address: B3:0/16. It was able to successfully change the first bit in B3:1. The format of the input address did change for 7.3, but I will need to talk to our Allen-Bradley driver developer to learn why.
Our concern is the File/Bit notation, not File:Word/Bit. The driver isn’t addressing as it has in the past. Did you try B3/16 and not B3:0/16? I’ve never seen B3:0/16 notation (there is only 16 (0-15) bits per word) but maybe it is valid also? You are correct that B3:0/16 returns a value - are you saying you need :0/bit number to access above the first word? This used to be accessible by just B3/16 and the word was interpreted internally.
OK, that now makes sense. I was able to compare the B3/16 behavior between 7.2 and 7.3 and confirm that 7.3 doesn’t read the tag in that format. As with the changing input format, I will need to ask our Allen-Bradley developer why this has changed between 7.2 and 7.3.