I’m having a recurring problem where my backup gateway is connecting to a device which only allows a single connection, and then not releasing that connection when the primary comes back. The device is a Lantronix serial/network adapter, and we’re reading off of it using Ignition’s TCP Driver. It’s not difficult to resolve, but it does require someone with access to the gateway to disable and then re-enable the device, after which the master gateway gets its connection back. So I have two questions:
-
Is there some way that I can script out a command to disable and re-enable the device, such that an operator can press a button on one of their windows to fix this? It happens frequently enough, and at odd enough hours, that I’d like to let them fix it themselves when they see it’s a problem, rather than having to wait until they can get hold of someone with access to the gateway.
-
Why is this even happening? I would have thought that a cold backup would not even be trying to connect to devices. But I’m looking in my logs, and that cold backup is constantly trying to connect to that address, and complaining that it can’t.
Thanks,
Dan
It shouldn’t be trying to connect if the backup is in Cold. You can turn the logger for that particular device to DEBUG level and watch for messages about redundancy activity level and maybe we’ll get a better idea of what’s happening.
Should we be seeing those redundancy activity level messages right away? It logged over 2000 lines of DEBUG info in less than a minute on the primary, all of which were regarding data arrival and payload handling.
When I changed the logging level on the backup to DEBUG, it logged a failure to connect every 5 seconds instead of every minute, and it logged a “Connecting to 10.19.50.129:10001…” along with each connection refusal.
Ah, that’s the ticket… I missed that this was the TCP driver. It doesn’t share the same base as many of the other drivers do and as a result must not currently be redundancy aware. We’ll have to implement this in an upcoming release.
That explains it. So a solution to the root cause will have to wait until another release.
In the meantime, is there something I can do to access the device configuration from a screen in the vision module? I would really like to let these operators fix the problem themselves, but I really can’t give them direct access to the gateway. I have found that the easiest way to fix this is either disabling the device and then re-enabling it, or changing its IP address to a fake value and back. Can we let the operators do this somehow without letting them into the gateway?
For what it’s worth, there is an answer to the first of my two questions, namely how do I give the operators a way to fix this themselves without calling me when it happens in the middle of the night. And that answer is to download the (free) IA Labs Scripting Module, which includes a script that can set the an OPC device’s Enabled property to True or False. With that, I can give the operator a button to repair the faulty connection themselves.
1 Like