I have had this issue several times on various gateways. When a gateway is restarted, sometimes the device connections don’t start up correctly as indicated in the attached image. I’ve had the same thing happen when disabling/enabling a device before. Any thoughts on why this happens and how to prevent it?
@jlteel did you ever find a solution to this? I am having the same issue.
Look in your logs for warnings/errors related to locking of the internal database…
I honestly can’t remember what I ended up doing, probably just living with the issue. I think Phil has a good suggestion. It’s probably related to the internal database being locked. If you can migrate to version 8.x, this problem may go away.
This is the error I am getting related to that issue. It looks to me as if the system is mad because we have 2 of the same connection when that isn’t the case. This driver is brand new. The client got it maybe 2 days ago. We tried restarting the gateway and that didn’t help (and also faulted the gateway for some reason, but that is unrelated…hopefully)
java.lang.IllegalArgumentException: A metric named drivers.BMS Siemens 1200.item-count already exists
at com.codahale.metrics.MetricRegistry.register(MetricRegistry.java:91)
at com.inductiveautomation.xopc.driver.api.AbstractDriver.(AbstractDriver.java:150)
at com.inductiveautomation.xopc.driver.api.AbstractSocketDriver.(AbstractSocketDriver.java:46)
at com.inductiveautomation.xopc.drivers.siemens.S7Driver.(S7Driver.java:118)
at com.inductiveautomation.xopc.drivers.siemens.S71200Driver.(S71200Driver.java:9)
at com.inductiveautomation.xopc.drivers.siemens.configuration.S71200DriverType.createDriver(S71200DriverType.java:49)
at com.inductiveautomation.xopc.server.devices.DeviceManager.loadDriver(DeviceManager.java:240)
at com.inductiveautomation.xopc.server.devices.DeviceManager.access$100(DeviceManager.java:30)
at com.inductiveautomation.xopc.server.devices.DeviceManager$RecordListener.recordAdded(DeviceManager.java:287)
at com.inductiveautomation.xopc.server.devices.DeviceManager$RecordListener.recordAdded(DeviceManager.java:279)
at com.inductiveautomation.ignition.gateway.localdb.PersistenceInterfaceImpl.notifyRecordAdded(PersistenceInterfaceImpl.java:168)
at com.inductiveautomation.ignition.gateway.redundancy.RedundantPersistenceInterfaceImpl.doNotifyRecordAdded(RedundantPersistenceInterfaceImpl.java:77)
at com.inductiveautomation.ignition.gateway.redundancy.RedundantPersistenceInterfaceImpl$RecordUpdateListener.recordAdded(RedundantPersistenceInterfaceImpl.java:287)
at com.inductiveautomation.ignition.gateway.redundancy.RedundantPersistenceInterfaceImpl$RecordAddedMessage.notify(RedundantPersistenceInterfaceImpl.java:364)
at com.inductiveautomation.ignition.gateway.redundancy.RedundantPersistenceInterfaceImpl$RecordUpdateListener.receiveCall(RedundantPersistenceInterfaceImpl.java:279)
at com.inductiveautomation.ignition.gateway.redundancy.QueueableMessageReceiver.receiveCall(QueueableMessageReceiver.java:47)
at com.inductiveautomation.ignition.gateway.redundancy.RedundancyManagerImpl.dispatchMessage(RedundancyManagerImpl.java:722)
at com.inductiveautomation.ignition.gateway.redundancy.RedundancyManagerImpl$ExecuteTask.run(RedundancyManagerImpl.java:743)
at com.inductiveautomation.ignition.common.execution.impl.BasicExecutionEngine$ThrowableCatchingRunnable.run(BasicExecutionEngine.java:518)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
``If you're seeing N/A device status on Ignition Edge, then check your logs for "Device limit x reached! Will not start deviceName" with com.inductiveautomation.ignition.gateway.opcua.server.DeviceManager on DEBUG. This can be caused by restarting one of your modules(ie: Modbus Driver module, Logix Driver, etc). If this matches your scenario, this bug will be fixed in 8.1.26
As a quick workaround, restarting the OPCUA Module should help correct the device status