This lesson is part of the Tags in Ignition course. You can browse the rest of the lessons below.

LESSON LIST

Autoplay Off
Take topic challenge

Description

System Tags provide status about the system such as memory usage, performance metrics, and so on.

Video recorded using: Ignition 8.0

Transcript

(open in window)

[00:00] In this lesson we'll talk about System Tags. System Tags simply report information about the system, specifically the Gateway or Vision Clients and Designer Sessions. If we look in the Tag Browser here, we can see that there is a System folder. This is where the System Tags live. Now, if I select this System folder here, you'll notice that I can't click the little Add Tag dropdown here. If I right-click on the folder, I can't add new System Tags in here, I can't add any tags in here. So you can't add your own System Tags. Again, they're just being automatically returned by some entity in Ignition. Now if we expand this folder here, you can see that there are some subfolders. Starting with the Gateway, these tags here report information about the Gateway. So if I expand this here, we can see, for example, the uptime seconds, so the number of seconds since the Gateway last started. There's also some subfolders based on different functionality. So for example, if I go down to the Redundancy folder, I don't actually have Redundancy configured on this Gateway, but if I did, we would see some information such as the role of the Gateway that's active, is the master active, for example. Another way the System Tags differ from other tags is that they're read-only. So for example, this IsMaster tag here, I can't just toggle this and change the state. So if I tried to write to that tag here it does say that this is a read-only tag. If I go up to the Performance folder we can actually see, resource-wise, how the Gateway is doing. So, for example, memory usage. Now, a similarity between other types of tags and the System Tag here is if I double click on the System Tag we see our tag editor. So I can make some configuration changes to these as well as create some alarms or turn on history. So if I wanted some trends of resource usage I could simply turn on history here. Now, I'm not going to cover all of the different folders. A lot of them are somewhat self explanatory, but we'll have them listed in the user manual. So we'll back out of the Gateway folder here and we'll switch over to the Client folder. So this folder here, just to point it out, is in fact different than the Vision Client Tags folder down below. This is the System/Client folder. So these tags here report information about Vision Clients or the Designer. They do not report information about any other entities. So for example, in the Perspective module you have Sessions. These tags do not report information to the Sessions. Sessions can't actually use the tags in this folder here. So if we were to take a look under the System/Client folder here we see some more subfolders. If I go down to the User folder, you can see some information being reported about the user. So if I scroll down for example you can see the username I'm using to log into the Designer. Now these tags are kind of unique. So for example, if I were to double-click on this Username tag here, there is no tag editor that appears. I can't turn on history or add alarms or change the formatting on these tags here. Right-clicking on it doesn't give me the option, it's disabled. Part of this is because of the way they work. Basically, every copy of a Vision Client, every instance of a Vision Client, populates these tags with unique values, and they're only accessible to that one client. The Designer works in a similar way. So if I were to launch a client somewhere else, log in as a different user, that Username tag would have a value of whatever username I used in that scenario. So again, same tag path, different value per instance. However, you can utilize these in component bindings. So, for example, you could place an expression binding somewhere in a Vision Client that looked at, say, the RolesString or the RolesDataSet. So we know that these are tied specifically to designers and clients, so if you wanted something similar to these tags here in a Perspective session, that's what the Session Props are for. So the Session Props basically fill that role, they provide similar functionality, and again, they're really only available inside of the session. Now hopefully that gives you a good idea about what the System Tags are. Again, there's not really a lot of configuration you need to apply to them. They do offer some useful information that otherwise is somewhat difficult to obtain.

You are editing this transcript.

Make any corrections to improve this transcript. We'll review any changes before posting them.