Good OPC browse but bad tag quality

I’m connecting to a AB Compact Logix that is a couple of PLC hops from the Ignition server. The connection path looks like this

1,2,2,1.2.35.4,1,0,2,192.168.200.80,1,0

I can browse the PLC tags in the OPC browser as in I can see all the tags.

I create the OPC tag by dragging it from the OPC pallet to the Tag Pallet. The tag is made but the the tag is ‘Bad’

There are only 16 tags from this PLC that I’m interested in. I tried with a single tag from the PLC but the tag was still ‘bad’

The Ignition server version is 8.0.10 (b2020031912)

Any ideas on how to fix the bad tag quality?

What driver did you use and what is the firmware version of the target PLC at the end of the path?

Here is the info:

Allen-Bradley Driver 5.0.10 (b2020031912)
OPC-UA 8.0.10 (b2020031912)

PLC: 5370 Compact Logix
PLC Firmware 30.011
And I am using the Allen Bradly Logix Driver.

Go back to a single tag and then find and turn these loggers to DEBUG and see what they’re saying:

ReadTagsRequest
ReadArrayTagsRequest
ReadStructuredTagsRequest

which one actually logs something will depend on the type of tag it is.

Here it is with the trace on

ReadBrowseHashRequest 14Jan2021 16:12:41
Read browse hash: LogixBrowseHash{a1=364, a2=1, a3=-21151171, a4=-103826355, a10=-1212613931}
ReadTagsRequest 14Jan2021 16:12:41
Error reading 1 items: status=0x01 [connection failure] , additional=[0x0318]
ReadTagsRequest 14Jan2021 16:12:40
Error reading 1 items: status=0x01 [connection failure] , additional=[0x0318]
ReadTagsRequest 14Jan2021 16:12:39
Error reading 1 items: status=0x01 [connection failure] , additional=[0x0318]
DriverAdapter 14Jan2021 16:12:39
getReferences nodeId=NodeId{ns=1, id=[RS2Bagger]Controller:Global}
ReadTagsRequest 14Jan2021 16:12:38
Error reading 1 items: status=0x01 [connection failure] , additional=[0x0318]
ReadTagsRequest 14Jan2021 16:12:37
Error reading 1 items: status=0x01 [connection failure] , additional=[0x0318]
DriverAdapter 14Jan2021 16:12:37
getReferences nodeId=NodeId{ns=1, id=[RS2Bagger]}
ReadBrowseHashRequest 14Jan2021 16:12:36
Read browse hash: LogixBrowseHash{a1=364, a2=1, a3=-21151171, a4=-103826355, a10=-1212613931}
ReadTagsRequest 14Jan2021 16:12:36
Error reading 1 items: status=0x01 [connection failure] , additional=[0x0318]
ReadTagsRequest 14Jan2021 16:12:35
Error reading 1 items: status=0x01 [connection failure] , additional=[0x0318]
ReadTagsRequest 14Jan2021 16:12:34
Error reading 1 items: status=0x01 [connection failure] , additional=[0x0318]
ReadTagsRequest 14Jan2021 16:12:33
Error reading 1 items: status=0x01 [connection failure] , additional=[0x0318]
ReadTagsRequest 14Jan2021 16:12:32
Error reading 1 items: status=0x01 [connection failure] , additional=[0x0318]
ReadBrowseHashRequest 14Jan2021 16:12:31
Read browse hash: LogixBrowseHash{a1=364, a2=1, a3=-21151171, a4=-103826355, a10=-1212613931}

Hmm. I don’t know why the browse would work but then when reading the device would return an error code instead.

If you can get a Wireshark capture from the Ignition server where you start it, then edit/save the device in the gateway, then let at least one failed read occur, that might help.

I’ll get that going. Thanks for the help. More to follow tomorrow.

It might have something to do with CIP unconnected vs connected messaging. Browsing and that “ReadBrowseHashRequest” you’re seeing in the logs use unconnected messaging. Read and writing tag values requires using connected messaging, which requires that a logical CIP connection be established via the ForwardOpen service.

You have 3 different PLCs involved here - if any of these are unable to establish a connection to the next or have a connection opened, e.g. because it’s already got too many connections to it, that might explain what you’re seeing.

I would check this part out--all but the very latest Logix processors have strict limits on total connection counts. And chassis-based network devices (ENBT, etc) also have connection limits.

This document has more information in Chapter 3:

Logix 5580 and 5480 processors have communications coprocessors that apparently lift these limits for their built-in ports.