A remote Tag Provider uses the Gateway Network to grab a Tag Provider from another Gateway on the Gateway Network, allowing you to share Tags between networked Gateways. A remote Tag Provider works like a normal Tag Provider in that you can edit the Tags and read or write to the values. These Tags are shared between Gateways without the need for additional OPC connections, allowing for a more streamlined flow of data.

Video recorded using: Ignition 7.9


(open in window)

[00:00] <v ->Setting up a remote tag provider in Ignition is easy,</v> but there are quite a few settings that allow you to customize exactly how it works. Before we get started, you will first need to ensure that you have two separate gateways. You can see that I have one installed locally and one installed on a remote machine. In addition, you will need to make sure both of these gateways are connected through the gateway network. Once we have all that set up, we're then going to want to go into the configure section of one of our gateways. We're going to want to scroll down and go to the Realtime page here on the left. Now if you already have some tag provider set up here, don't worry about it. We're just going to want to go and click this create new Realtime tag provider link down below. We're then going to want to click the remote tag provider option and go to the next page and here we can see I have my remote gateway listed. If there were more gateways in my gateway network they would also appear here, but since I only have the one, I'm going to make sure it's selected and hit the next button.

[01:14] Here we will see a list of the tag providers on that remote gateway. You will notice that I only have the tag provider called default and the tag provider called system. The system provider includes all of the gateways built in system tags. So, I'm going to choose default as my tag provider instead and click the next button. This last page is where we can customize exactly how this tag provider works. The default name that it's given is going to be a combination of the remote gateway's name and the tag provider. So since my remote gateway's name is remote gateway and the tag provider is default, its combined those to make this new name. But you can change that if you would like. I can make a list of roles that the user must have in order to edit any tags in this tag provider. And here you can see the gateway and provider sections got filled in automatically based on my choices from before.

[02:08] But I can also manually type in anything in there as well. Here in the history setting section, we can choose how we want to handle history that may already be set up on some of the tags. Normally, tag history queries are sent through the gateway network, but I can also choose to send them directly to the database if I have a connection to the database on my local machine that the remote gateway is using. If the local gateway is connected to the database, then you can use these settings down here to identify that database connection after setting the history access mode to database. Finally, I can choose how alarms are going to be handled with these tags. Alarms can either be queried through the gateway network when necessary, or they can be directly subscribed to which will usually be faster, but it will use more memory than queried mode. Once we have all of our options set, we can go ahead and click the button at the bottom that says create new realtime tag provider.

[03:08] You can see that it has now created our new remote provider. Let's go ahead and take a look at those tags in the designer. I already have a pair of designers open. One for my local gateway and one for my remote gateway. On the remote gateway, we can take a look at the tag provider called default to see what kind of tags we would expect in the remote provider that we just set up on our local gateway. In the local gateway's designer, we can go to the all providers folder and you'll notice we have our new remote tag provider here. If we expand it, you'll notice it has the same tags as the tag provider called default in the remote gateway. If the value of the tag were to change, say from 10 to 12, you'll notice that it also updates on the remote tag provider on the local gateway. There is, however, one very important thing that I want to make note of and it's about service security.

[04:06] If you've never set up any security zones or played with the service security settings then when you try to change a tag from the remote tag provider on the local gateway, you'll notice that you get an error message and it says access denied. This is because of the way I have service security set up. To learn more about service security please watch the security zones and service security video. Once I have set up security properly, I can go ahead and close this error and then I can enter in a value into the tag on the remote tag provider and you'll notice it also updates in the actual tag provider on my remote gateway. Finally, it is important to understand what it means that the tags are going to be stored and executed from the gateway they originate from. While it may look like the tags are storing history here the tags are actually on the remote gateway and storing history using the remote gateway's history providers.

[05:03] In addition, any tags that I create or delete on this remote tag provider here will actually be created and deleted on the provider that they originate from on the remote gateway.

You are editing this transcript.

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