This keeps coming up in my console…
Time Logger Message
4:55:38 PM DeviceSubscriptionModel NodeId "[TRANSFER 1100 SCANNER]_Meta:[Diagnostics]/Requests/@100ms/Maximum Duration" not found on device "TRANSFER 1100 SCANNER".
com.inductiveautomation.xopc.driver.util.AddressNotFoundException: Address “_Meta:[Diagnostics]/Requests/@100ms/Maximum Duration” not found.
at com.inductiveautomation.xopc.driver.common.nodemap.NodeMapDriver.checkAddress(NodeMapDriver.java:204)
at com.inductiveautomation.xopc.driver.common.nodemap.NodeMapDriver.buildNode(NodeMapDriver.java:151)
at com.inductiveautomation.xopc.server.devices.AbstractDevice.buildNode(AbstractDevice.java:152)
at com.inductiveautomation.xopc.server.devices.DeviceSubscriptionModel$FailedResubscriber.run(DeviceSubscriptionModel.java:167)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(Unknown Source)
at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(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)
You must have whatever logger is logging that set to DEBUG then, yeah?
Also, for whatever reason, that diagnostic tag doesn’t exist.
I am watching as my UDT scanners are connected and listening.
Here is what I am experiencing.
The Message and the Last Receive Time are not changing even though my scanner is reading scans in SOPAS software. To fix this problem, I edited the device configuration and saved it, I made no changes.
Ignition began reading the scans again.
Does anyone know why this is happening?
This was on the console around the time I stopped reading scans.
Both the quality and the driver on the scanner appeared to be working properly and the scanner was a SICK scanner.
I am seeing this more frequently now.
The scanners drop out and stop reading, then I reset the device in the gateway, problem solved.
Is there a fix coming for this?
[quote=“BigSchottkyD”]I am seeing this more frequently now.
The scanners drop out and stop reading, then I reset the device in the gateway, problem solved.
Is there a fix coming for this?[/quote]
Is this still an issue? are the scanners you’re talking about using the generic TCP driver?
Sunday I had a scanner stop receiving Scan data. I logged 10 noreads in a row and reset the driver and starting reading again.
I had two scanners act very strangely today. The scripts I have to log my scans are triggered by the Lastrecievetime of that scanner.
I was seeing triple logs today which was causing series problems.
I am using the generic TCP driver on these.
This is the first issue I’ve had in a month on this project running 7.5.8 version of Ignition.
I edited the device, changed nothing, and clicked save. Everything is working again.
Here are settings on one of my scanners.
7.5.10 and 7.6.2 have rewritten implementations of the TCP driver that will probably solve your issues.
Be careful upgrading, however, the addresses for some of the tags provided by the driver had to change to accommodate thew new implementation, so you’ll have to drag the tags in again or update the item paths.
thanks Kevin, I’ll give 7.5.10 a try tonight!
We are seeing duplicate data in our tag change script. I’ve included some screenshots below. It appears that we will get the same data (sometimes blank) with the same timestamp, or we might get the same data (with some time between them) which shouldn’t be happening. If you can shed any light on this it would be appreciated.
See if you can log the quality or at least log it to the console - changes in quality will trigger tag change scripts even if the value or timestamp didn’t change.
If the tag quality of the last receive time of the scanner port changes from good to bad, the script will fire on that change as well as bad to good?
Is there a good way to restrict this from happening in the tag change script?
What could I look for?
[quote=“BigSchottkyD”]If the tag quality of the last receive time of the scanner port changes from good to bad, the script will fire on that change as well as bad to good?
Is there a good way to restrict this from happening in the tag change script?
What could I look for?[/quote]
In your tag change scripts you get the new value of the tag, but it’s a qualified value. You can just test against that to make sure the quality is good. From the manual:[code]print “Received tag change event for %s” % event.tagPath
value = newValue.value
quality = newValue.quality
timestamp = newValue.timestamp
print “value=%s, quality=%s, timestamp=%s” %(value, quality, timestamp)[/code]Then you can do something like:if int(newValue.quality) == 192:
#do something