Whenever we restart the ignition gateway, one of our SLC5/04’s (out of 5) opc driver fails to connect. The error is as follows.
com.inductiveautomation.xopc.driver.util.AddressNotFoundException: "P0:0" is not a valid address.
at com.inductiveautomation.xopc.drivers.allenbradley.address.ABAddress.(ABAddress.java:45)
at com.inductiveautomation.xopc.drivers.allenbradley.address.ABSLCAddress.(ABSLCAddress.java:13)
at com.inductiveautomation.xopc.drivers.allenbradley.requests.ABSLCBrowseRequest.processProcessorModel(ABSLCBrowseRequest.java:206)
at com.inductiveautomation.xopc.drivers.allenbradley.requests.ABSLCBrowseRequest.receiveMessage(ABSLCBrowseRequest.java:139)
at com.inductiveautomation.xopc.drivers.allenbradley.requests.ABSLCBrowseRequest.receiveMessage(ABSLCBrowseRequest.java:33)
at com.inductiveautomation.xopc.driver.api.BasicRequestCycle$PendingRequest.receiveMessage(BasicRequestCycle.java:434)
at com.inductiveautomation.xopc.driver.api.BasicRequestCycle.deliverMessage(BasicRequestCycle.java:201)
at com.inductiveautomation.xopc.driver.api.BasicRequestCycle.messageArrived(BasicRequestCycle.java:183)
at com.inductiveautomation.xopc.driver.api.AbstractDriver.messageArrived(AbstractDriver.java:853)
at com.inductiveautomation.xopc.driver.api.AbstractSocketDriver.messageArrived(AbstractSocketDriver.java:192)
at com.inductiveautomation.xopc.driver.api.AbstractSocketDriver$DriverIOEventHandler.lambda$deliverMessage$0(AbstractSocketDriver.java:253)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
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)
All of the SLC5/04’s are setup the same as far as communications go, and the drivers configured the same with the exception of the address.
SLC5/04 → DH+ → 1756-DHRIO → 1756-ENBT → Ignition Gateway
On all of the SLC5/04’s i get the following warnings following a gateway restart:
ABSLCConnectRequest: Initialization request failed due to DISCONNECTED.
ABSLCConnectRequest: Initialization request failed due to TIMEOUT.
But all the others do connect without further intervention.
With the SLC that is not connecting, i have to go into Config/OPC UA/Device Connections, click edit on the driver, then click save settings. After doing this it connects and i have no more issues until the gateway is restarted again.
I vaguely recall there being a bug in ethernet reconnection that looks like this. @Kevin.Herron ?
I don’t recognize this error message at all:
AddressNotFoundException: "P0:0" is not a valid address.
but in terms of reconnection bugs the only one I can think of is resolved by setting the connection path to 1,0 (the implicit default when not configured), which prevents the driver from cycling through different transports options as it connects and reconnects.
The path currently set is 1,8,2,13 as we are navigating through a clx backplane/dhrio card to get on the dh+ network. Yes, i live in the land of obsolete.
Off subject but this has me thinking that i may be better off having the ControlLogix processor grab the data from the SLC and then just have ignition read the relevant tags from the ControlLogix instead of going out over the DH+…
I’m basically doing code archaeology here, without a real understanding of what I’m seeing, but it seems during the browse the driver expects to receive a processor model of 503, 504, or 505, and in this case it’s receiving nothing / empty buffer, so the “address” it constructs and subsequently complains about ends up being P0:0 instead of 504P0:0 or something to that effect.
Unfortunately I have no idea what this means…
2 Likes
Are they all going through the same DH+ network or something? Maybe all 5 starting up at once is overloading it or something like that.
edit: oh, yeah, you said that already. Hmm.
Yes they are, and i can see that as a possibility, but it is odd that it is only that one that seems to have the trouble. But being that it is the “master” and coordinates the others it is a lot busier on the coms front than the others. That being said, i don’t think it is anywhere near its max capability. I’m going to set AABSLCBrowseRequest to debug/trace and restart the gateway when i can and see if there is anything that looks helpful there.
Set drivers.SLCEthernetDriver and every sub-logger to TRACE, which should include the requests.
Unfortunately setting log levels doesn’t persist across gateway restarts, but you might be able to reproduce by just restarting the OPC UA module instead.
1 Like
Good to know, i’ll give that route a shot. Thank you
It appears that just restarting the OPC UA module does not exhibit the same behavior. It came back up fine.I’ll probably drop this issue right here as it really isn’t a big enough deal to warrant putting any more time into it. And this is one more bit of ammunition that can be used to try and get out of the bronze age.
2 Likes
I still have one customer with that same setup. And still on v7.9. (Though they do plan to fix the latter.)
1 Like