I'm having difficulty connecting to a Logix5584E. The rack is laid out as shown below.
Slot
0
1
2
3
4
Device
Logix5584ES
Logix55L8SP
Logix5584E
EtherNet/IP
Logix5581E
Name
1756-L84ES/B
1756-L8SP/B
1756-L84E/B
1756-EN2T/D
1756-L81E/B
IP address
192.168.1.3
192.168.0.4
WAN access
NAT via router
(There's also a 1756-1B16ISOE/A and a 1756-OB16IS/A SCHEDULED OUTPUTS but they're not relevant.)
I want to set up an OPC UA device connection to the PLC in slot 2.
I'm able to connect to the Ethernet module in slot 3 from my WAN and display its webserver page and browse the chassis.
I have created a Allen-Bradley Logix Driver OPC UA device connection to the PLC using the Ethernet module's WAN address and the Device Connections page shows that it is connected.
When I use the OPC Quick Client I can see the Diagnostics section but there are no browsable tags from the PLC.
The configuration page is set with the correct WAN address for the Ethernet module and all the other settings are default except that I've set Slot Number = 2.
Can you reach it in a browser from the same machine the Ignition Gateway is running on? Does the device status change to connected or cycle between other states?
Set the log level for the logger you find searching "LogixBrowse" and "LogixBrowseStateManager" to TRACE and then edit/save the connection and upload the logs. Bonus points for Wireshark capture too.
Thanks, Kevin. I haven't done this level of debug before.
Browse failed: status=0x08 [service not supported] ,
additional=[0x00FF]
Details are as below.
com.digitalpetri.enip.cip.CipResponseException: status=0x08 [service not supported] , additional=[0x00FF]
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$invoke$2(CipClient.java:124)
at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture.postComplete(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture.complete(Unknown Source)
at com.digitalpetri.enip.cip.CipClient.lambda$sendUnconnectedData$8(CipClient.java:222)
at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture.postComplete(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture.complete(Unknown Source)
at com.digitalpetri.enip.EtherNetIpClient$PendingRequest.lambda$new$0(EtherNetIpClient.java:412)
at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture.postComplete(Unknown Source)
at java.base/java.util.concurrent.CompletableFuture.complete(Unknown Source)
at com.digitalpetri.enip.EtherNetIpClient.onChannelRead(EtherNetIpClient.java:220)
at com.digitalpetri.enip.EtherNetIpClient.access$900(EtherNetIpClient.java:50)
at com.digitalpetri.enip.EtherNetIpClient$EtherNetIpClientHandler.lambda$channelRead0$0(EtherNetIpClient.java:346)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
I don't know what else to suggest. I'm pretty sure you're not actually hitting a Logix device in the end. I don't know if that's a NAT configuration error or something else.
I got this working eventually using the Allen-Bradley Logix Driver and the working configuration is using Slot 2 as in my original post.
I don't remember finding the cause of the problem but we were developing some peculiar NAT routing rules at the time to get around some other problems. It may have been related to this.