ControlLogix firmware 31 connectivity

Ignition
1

I updated a 1756-L85 ControlLogix from v28 to v31 today and lost my tag connections. I’m making my connection through this processor’s built in Ethernet port (both before and after update). The PLC shows connected on the status page, but the tags are bad quality even though I can browse to them. I tried deleting and recreating the device and tried assigning the slot field as the actual slot and also as 0.

Changing my path to route through a 1756-EN2T Ethernet card in the chassis instead of directly to the processor works.

Is this something which is known and has been fixed in later Ignition versions? I’m using Ignition 7.9.9 for a few more weeks until it will be updated.

2

What version of Ignition?

3

If you only changed the firmware and didn’t change anything in Ignition I’m not sure what the difference would be. Does the diagnostics page for that device show that requests are happening? What’s the load?

I think 7.9.9 and 7.9.10 have some unfortunate performance regressions that are fixed in 7.9.11, but again, if nothing else changed it shouldn’t matter.

4

7.9.9

5

With it working through the EN2T I have 452 tags connected at 1000ms scan rate with a 5% load. When I change it back to the processor I don’t have a details button to look at the diagnostics. I tried to browse to a tag again and cannot, I only see the OPC diagnostic tags. I’m thinking it only let me do this before I deleted the driver and recreated it. I’m sure I did it (by browsing through the tag editor, the OPC-browser did not work). The PLC firmware is 31.011.

I will be updating to 7.9.11 soon and will see if that fixes the issue. I don’t have a problem leaving it routed through the EN2T. I was just surprised that it stopped working.

Do you think a restart of the Ignition service would help. And in the case of a L8 processor when using the built-in Ethernet does the slot setting matter?

6

No, not really.

Connection path should be 1,0 in that case. (or just leave it empty)

7

There might be something useful if you set the level to DEBUG for loggers you find searching for “LogixBrowse” (when connected directly, since that’s the case where you can’t see tags in the OPC browser).

8

This logs when I try to browse to a tag using this device.

LogixDriver Time:
27Jun2019 14:22:56
Message:
Browse failed: status=0x01 [connection failure] , additional=[0x0204]
:

com.digitalpetri.enip.cip.CipResponseException: status=0x01 [connection failure] , additional=[0x0204]

at com.digitalpetri.enip.cip.services.GetAttributeListService.decodeResponse(GetAttributeListService.java:45)

at com.digitalpetri.enip.cip.services.GetAttributeListService.decodeResponse(GetAttributeListService.java:12)

at com.digitalpetri.enip.cip.services.UnconnectedSendService.decodeResponse(UnconnectedSendService.java:122)

at com.digitalpetri.enip.cip.CipClient.lambda$invokeUnconnected$2(CipClient.java:112)

at java.util.concurrent.CompletableFuture.uniWhenComplete(Unknown Source)

at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(Unknown Source)

at java.util.concurrent.CompletableFuture.postComplete(Unknown Source)

at java.util.concurrent.CompletableFuture.complete(Unknown Source)

at com.digitalpetri.enip.cip.CipClient.lambda$sendUnconnectedData$8(CipClient.java:201)

at java.util.concurrent.CompletableFuture.uniWhenComplete(Unknown Source)

at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(Unknown Source)

at java.util.concurrent.CompletableFuture.postComplete(Unknown Source)

at java.util.concurrent.CompletableFuture.complete(Unknown Source)

at com.digitalpetri.enip.EtherNetIpClient$PendingRequest.lambda$new$0(EtherNetIpClient.java:309)

at java.util.concurrent.CompletableFuture.uniWhenComplete(Unknown Source)

at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(Unknown Source)

at java.util.concurrent.CompletableFuture.postComplete(Unknown Source)

at java.util.concurrent.CompletableFuture.complete(Unknown Source)

at com.digitalpetri.enip.EtherNetIpClient.onChannelRead(EtherNetIpClient.java:188)

at com.digitalpetri.enip.EtherNetIpClient.access$500(EtherNetIpClient.java:34)

at com.digitalpetri.enip.EtherNetIpClient$EtherNetIpClientHandler.lambda$channelRead0$0(EtherNetIpClient.java:245)

at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(Unknown Source)

at java.util.concurrent.ForkJoinTask.doExec(Unknown Source)

at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(Unknown Source)

at java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)

9

This indicates “UNCONNECTED REQUEST TIMED OUT”.

Not sure why, but the processor is returning this while we’re doing the browse and the browse is subsequently failing. Don’t know why it likes you going through the EN2T better. Maybe there’s already too much load on the processor from the built-in port and it’s dropping these unconnected requests and prioritizing connected ones.

@pturmel or some other ENIP genius might have ideas as well.

edit: ah, try increasing the “Communication Timeout” setting from 2000ms to something larger. This gets sent as a hint about how long we’re willing to wait for an unconnected request. If the processor thinks it won’t finish within that timeout hint it will respond like this as well.

10

Sorry Kevin. This was all due to my fat fingers with the IP addresses. It’s working fine now as it should. I will point out that the slot number needs to be set to the actual slot number in the rack rather than 0. I happen to have another processor in slot 0 and it was bridging over to that one before I changed that. That did prolong my confusion.

Thanks for the quick responses.

11

Yes if you're going through a card and into a rack you have to actually set a connection path and choose a slot number. When that field is left blank it's equivalent to "1,0", which is usually okay when you're making a direct connection via a processor's built-in ethernet port.

12

I’ve noticed within RSLogix that Rockwell’s newer firmware exhibits different behavior when addressing a processor through its built-in network ports (ethernet port UCMM) versus a hop through the chassis and into the processor’s backplane UCMM. In particular, RSLogix does not want to connect to such processors with the “1, 0” connection path via the built-in port.

ODVA has in recent CIP versions deprecated that distinction (port-specific UCMM resources) but that doesn’t mean Rockwell has gone along. It might become (or already be) necessary to accommodate no connection path at all. Perhaps, when connection path is empty, by interrogating the port properties to see if the requested backplane slot is the first-hop device’s own backplane address (Port Object Instance Attribute 7). That would catch the case above where the processor is not in slot 0.

3 Likes