Data Type Parameter “TagName” after upgrade to 7.7.x

In 7.7.0, there were some changes made to UDTs regarding the use of TagName as a data type parameter in a UDT. TagName became a reserved keyword that was used behind the scenes in all UDTs, and upgrading to 7.7.x with TagName being used as a parameter caused the parameter to be overwritten in the UDT instance wherever it was used. Follow the steps below to determine if this is your issue, and how to fix it.

What to look for:

Below you can see a basic UDT definition. It includes both a tag named TagName, and a parameter called TagName. One important distinction to note is that any tags that are named TagName are fine just how they are. The only thing we want to change is parameter called TagName.

Now take a look at the image below. You can see in the Tag Editor that the TagName property’s value has been highlighted. In this case it is “Sensor 1”. You can also see a highlighted humidity tag, which is faulted, along with its OPC Item Path, which is also highlighted. You can see, in the highlighted portion of the path is the word “Humidity”. This is where the TagName parameter is, so it should say “Sensor 1” there, but it is now being overwritten with the tags literal name, which in this case is “Humidity”. Finally, the value of the TagName memory tag is also highlighted. For this tag, the value of it should be the TagName parameter. So, this value should be coming in as “Sensor 1” but is coming in instead as “TagName”, because that is the literal name of the tag.

How to fix:

Step 1. I would recommend taking a gateway backup, just to be safe, but you will need to export all of your tags and UDT definitions. This is done by ensuring you have all your tags and UDTS selected. Notice in the image below that the Data Types folder has been expanded to show all of my UDTs. In this case, there is only one, but you will want to make sure all UDTs are highlighted, as well as all of the other tags. Expanding a folder with tags in it, such as My Folder, which just has UDT Instances or other tags in it, does not need to be expanded. You can then export this into a safe location.

Step 2. Make a duplicate export of the tags, but export it with a different name. This way, there is a copy of the originals, and a copy that can be modified.

Step 3. Open the xml file that you are going to modify with a text editor like Notepad++.

Step 4. Do a find for “TagName”. If you move between occurrences, you will see a few different areas where you will find “TagName”. This may vary slightly from user to user, but I have detailed what to look for below.

In the above picture, you can see that there are two instances of “TagName”, both of them are parameters of a UDT instance. These we will want to change.

In the image above you will see a few more examples of instances of “TagName” in the xml file. In the non-circled instances, you will see that they are all parts of either the Parameter, or they are properties being used like {TagName}. These need to be changed. The one that shouldn’t be changed is the circled instance of TagName. If you look closely, you will notice that this relates to the name of the TagName tag, which can be left alone. The reason for leaving it alone is if it is used anywhere in the project bound to a component, then the bindings won’t change the tag path to include the new tag name, which would be problematic. So you want to do a find only for the instances that we want to replace, and then replace them with something else. In this case, the instances of TagName that need to be replaced are either:

1. "TagName" type

Or

2. {TagName}

The instance that doesn’t need to be replaced looks like:

“TagName” path

*Note: this may not be true for everyone. Be sure to look through the xml to ensure that you are replacing the correct instances. Also, if there are no tags named TagName that you are trying to save, then you won’t have to worry about this as much.

Step 5: Do a find for the instances you want to change, in this case (“TagName” type), and do a replace all, replacing the part in quotes with something else, like (“TheNameoftheTag” type). Do this for all instances of TagName that we want to change. In this case, the only other one is {TagName}. Be sure that the part you are replacing is the same across all replacements, so my {TagName} would become {TheNameoftheTag}.

Step 6. Save the xml file

Step 7. Back in your designer, highlight the topmost folder of your Tag Browser, normally named “Tags”, and import your newly edited xml file.

Step 8. You should now see your UDT parameter have a different name, and all instances where it is used should have the correct value. If you look at the picture below, you will see all tags coming in properly.