I’m not sure what happened. I had a lot of tags configured for 3 different PLCs. I went to a customer for a couple days and came back to the office. All of my tags in my tag database are gone. The folders are still here but the tags are gone.
Where can I view logs to get some information about what happened?
The computer that lost its tags can not see any of the PLCs that the tags are in. I’m wondering if there is a bug that causes the tag db to lose tags that are resolving in error.
Some more details. I went over the entire project and it wasn’t just tags that changed. I had a number of controls on various screens that had a custom property I had added which was bound to a tag (used to indirectly bind various animations on the object from one binding). Those custom properties in some but not all situations were gone. The control remembered the tag I had bound to the custom property when I re-added it to the control.
Weird bug. That said, my build is a few days back and I understand a new build is coming that fixes problems with modbus tags (these are modbus tags) and a new build that is adding a lot of things is coming next week.
For now, I fixed all the stuff to got corrupted and made backups. I’ll report it as a bug if it happens again on a newer build.
Any new information for us? This is something that sounds pretty serious, but is ultimately impossible to troubleshoot based off what you’ve supplied so far. Was this after you updated to a new nightly? Did this happen without upgrading?
The “properties were gone, but they remembered their value when I re-added them” tells me that you did indeed have those properties in place and saved, and that the property was either manually deleted or an upgrade occurred (the component schema retains property values, even if you remove the property in the Designer). So something happened which removed the property from the component. The “some but not all” leads me to believe it was either manual, or the components which were missing the properties were all of the same type as a schema definition change would only apply to a certain component type.
Sorry, I was trying to figure out how to see any errors in my log to see if there were any. I was also trying to see if anyone else had this occur and that does not appear to be happening.
The first time it happened was before I had applied any nightlies so it may have been a bug in a past patch. I fixed my tag database and it was fine for 3 nightly patch updates without incident. Then I was out of the office again for a few days and when I returned to the office and it had happened again but only on one of my tag folders. Both times this happened it would effect all tags in a folder but then not effect other tags in other folders. I don’t have any PLCs on the network that this computer is on so all of my tags are constantly in error.
I had made a backup of my project and my tag database before going out of the office again. The problem happened again but only on one folder of tags. I went to restore the tag database backup (xml) I had made after fixing my tags from the first occurrence of this issue and it threw an error. I opened the XML in a text editor and discovered that I had a blank tag (missing properties including tag name) in my XML backup. I manually corrected that issue in the text editor and recovered my tags without incident. I had created that XML tag dump directly from Ignition’s tag export. That said, it may be possible that the tag import XML I started with created some tags wrong in Ignition causing my XML export to retain the problem (creating an invalid XML import file).
It looks like no one else is having this problem so I assume I did something other people haven’t done while testing. I will describe the history of my project. If you want to know more details about any of this just let me know.
I had Ignition 7.9 installed on my test machine. I had imported tags into that project by programatically creating an XML tag import file from a spreadsheet. So basically, I wrote a custom program to create my tag import file and imported that into Ignition 7.9. Those tags were stable in Ignition 7.9 for about a week.
Next, I installed Ignition 8 on that machine and everything was fine for about a week. The problem happened when I was out of the office for a few days on an earlier beta patch. I assumed the problem was an issue with the version of beta that I was running so I fixed my project and installed the latest patch roll up. Everything worked fine for a few days.
I wasn’t here and the computer was sitting here with the monitor off so it is certainly possible that something hit keys on the keyboard causing tags to be manually deleted. If the behavior I’m describing is consistent with someone deleting tags then that is certainly a possibility. I would say that’s unlikely because the folders weren’t deleted but tags inside the folders were.
Regarding the properties that disappeared…
I built the equivalent of a multi-state indicator using a label with a custom property called “State”. I bound the “State” property to a tag and indirectly bound various transforms to custom styles based on the value of the “State” property. I copy/pasted that control many times and simply changed the tag bound to the “State” property to display status on various tags. The only controls that lost their “State” properties were controls that were bound to tags that disappeared. All of the controls were created by copy/paste so they were identical aside from the tags their custom property was bound to.
I have not had this happen since I applied the latest patch and re-imported my repaired XML file. I was out of the office for a few days again and everything looks fine as far as I can tell.
I went out of the office again for a couple days and my tags are still fine. I think whatever happened is fixed in the last build you released or that blank tag I deleted from my import file was the culprit.
I just thought of another detail I should have mentioned. I didn’t have the beta license key so my trial was expired. I don’t know if that matters but I thought I would mention it.
Use of the license shouldn’t matter, but more info is always best. I’m glad to hear you’re not encountering the issue any longer, although we always prefer to be able to identify a root cause. If it happens again, please reach out.