I have a tag data type instance where one of the tags periodically goes null. I have 10 instances of this data type and I have had one of them go null several times and a couple others only a few times. if I change the data type instance property that points to the tag to something else and then change it back to the correct address it works fine again for a few days.
A few questions: what version of Ignition is this? Are there any related events happening in the gateway logs? What kind of device is providing these tags?
I seem to have made it through the weekend without any of them going null. One of my coworkers suggested changing its type from int4 to int2 and making it read only. Im not sure if that helped. its version 7.6.4. I haven’t spotted any related events. The instance thats dropping the most is a DL205 - the other 2 are modicon quantum through modbus plus bridge. The weird thing is I still have an ignition server running off my office computer which is version 7.6.2 (its one of the old free vision panel licences) and its monitoring the exact same DL205 and its never in the last 8 months ever gone null. Its not a UDT tag template instance though its just a directly configured tag and it was set up as boolean. would that make any difference?
Hi,
Once they’re up and running, the UDT tags are exactly the same as non-udt tags. However, the fact that they’re going to null value and “unknown” quality (which I see from the tag icon), which just happens to be the first value of a tag before the value comes in, suggests that perhaps for some reason the udt (definition or instance) is being modified and reloaded. This would seem unlikely, but could probably be triggered by a script or tag binding that writes to a “config” property of a tag in the udt… in other words, a property that isn’t value. Does this seem possible?
If it’s not the tag reloading, then it could theoretically be something going on with the OPC server. The console, which Kevin pointed you towards, might show the opc connection going down briefly, or something like that.
Another thing to look at would be to go to Status>OPC Connections when the tag is bad quality. Try to track down the tag in the list of subscriptions. Is it there? Is it’s value also null? The opc server won’t reset the value to null, it would only send bad quality, but if you see null in that list, it means the value was subscribed and never received a value. This would pretty much also indicate that the tag was getting reloaded for some reason at a later point.
Regards,
thank you I will look into that, none of them have gone null in a few days. im not really sure what to make of it but I’ll keep you posted.
Hi, we just upgraded to the version 7.6.4 and we have the same problem but involving memory tags. Sometimes the tags go null/unknown. We write the value of these tags using java code but never the quality, so there is nothing we can change in our code or Ignition’s configuration. This happens randomly and recovers in a few minutes, but there are some of these tags that are critical and our system collapses. Any solution other than going back to the older version we where using?
I still have some tags randomly going null but I havnt been able to pin it down. last week I had an entire folder with all the containing alarm tags go null.
The same is happenig here. The main issue is that it doesn’t follow a pattern, so it is impossible for me to narrow down the problem. If you find a lead, let me know! Thanks in advance!
Hi,
Let’s see if we can narrow down some possibilities:
Alcaan - you said: “We write the value of these tags using java code but never the quality”. How are you executing the write? Can you post an example? If you really are doing it in java, my suspicion is that you’re setting the value on a TagDiff and then calling edit, which could possibly lead to this.
cja7928 - Are the affected tags always in UDTs?
In both cases: If you go to Status>SQLTags in the gateway, and look at the executing scan classes, what kind of numbers do you see for “Last Execution Duration”? This wouldn’t be a cause, but I’m just curious.
Also, have either of you been in contact with support? Ideally I’d like to get the wrapper.log file(s) (from {installdir}\logs) that cover the time when this occurs. You could probably just zip them up and post them here, otherwise email them to support AT inductiveautomation.com, and say “for colby” in the subject or something.
Regards,
I have seen it in both UTD and regular tags. I dont have access to the Status (developer only). next time I see a null tag I will request our IT group get this info for me.
Hi,
Probably more important would be to get the log files, either on disk, or through the gateway from Config>Console>Logs>Export Logs.
Regards,
Hi,
Here is a example of code we use to write the memory tags:
public void writeValue(String tagPath, String value) {
try {
List<WriteRequest<TagPath>> writePaths = new ArrayList<WriteRequest<TagPath>>();
WriteRequest<TagPath> writeValue = new BasicAsyncWriteRequest<TagPath>(TagPathParser.parse(tagPath), value);
writePaths.add(writeValue);
tagManager.write(writePaths, null, true);
} catch (IOException e) {
logger.error("Error escribiendo el valor " + value + " en el tag " + tagPath, e);
}
}
Also attached screenshots for the scanclasses. The last error was the 17th and the logs fall short, we have a lot of noise and ignition only save a few days. I will save the logs as soon as a new error occurs and send them to you.
Here is the log and the graph when you can see the time of the error. Still happening randomly once or twice a week. I looked at the log, but didn’t find anything strange.
Hi,
For those two tags: what kind of scan class are they in? Is it a direct scan class, or a leased scan class? The log doesn’t show much, but it’s somewhat suspicious to me that it does show messages about a lost session more or less each time the values go flat… The session shouldn’t affect the tags, but it might be doing something to the subscriptions, which in turn might have an unintended consequence.
Also, what is the data source for those tags? Are they from the custom driver that is shown in the logs?
Regards,
Hi,
The two tagas are memory tags and the scan class is the default from Ignition. We change the value of the memory tags using a module. The code we use is this:
public void writeValue(String tagPath, String value) {
try {
List<WriteRequest<TagPath>> writePaths = new ArrayList<WriteRequest<TagPath>>();
WriteRequest<TagPath> writeValue = new BasicAsyncWriteRequest<TagPath>(TagPathParser.parse(tagPath), value);
writePaths.add(writeValue);
tagManager.write(writePaths, null, true);
} catch (IOException e) {
logger.error("Error escribiendo el valor " + value + " en el tag " + tagPath, e);
}
}
I can’t understand how using this code we can get a null value and unknow state in a memory tag and the problem being random it doesn’t help to narrow it. For us is a critical to solve this. The only think I can think now is to do a donwgrade on the version. Hope we can solve it before going that far! Thanks!
Hi,
The write looks like it’s probably fine, but again, what is the scan class set to? I’m really curious if the tags happen to be in a leased scan class. Even if not, I’m trying to figure out if by some long shot, the lost session messages might be related (my thinking is that lost sessions mean resubscription, and subscriptions do end up loading tags from the internal database, so maybe something is going on there).
Regards,
Here you have one of the memory tags and the scanClass. Let me know if it is useful!
I’ve been trying to test various scenarios, but I simply can’t come up with anything. You mentioned rolling back, is there a particular version where you know that this wasn’t happening?
Unfortunately the logging isn’t very helpful in this case, I can’t find anything that would help me narrow down what could be going on. I’ve got one idea, however, that might help me confirm or deny one idea:
You could try to set up a Gateway Tag Change Script on just that tag, and do something like the following:
print "Path: %s Value: %s Quality: %s Tag: %s" % (event.tagPath, newValue.value, newValue.quality, str(event.source))The “print” output will only write to the wrapper.log file in {InstallDir}\logs. The main point I’m curious about is the last parameter, the toString of the source, which should show me the actual instance hash of the tag. I’m curious if this changes when the null values occur. If you set this script up, as soon as you see a null event, send me (attach here) the wrapper.log file.
Regards,
I’ve been trying for weeks the gateway tag change script, but I couldn’t catch the bug in the log. The last version of Ignition without the bug was 7.6.2, now we are running the 7.6.4. As soon I get the bug in a log I send it to you. Thanks!
Hi, After not happening for a while (at least we didn’t notice in the important tags), the problem appeared again. You can see the moments that the value went null in the pics. Also you have the logs. Let me know if this info is useful to solve the problem!
log.zip (277 KB)
