[00:00] 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. If we set up a Remote Tag Provider on Gateway A, it'll create a link to the specified tag provider on Gateway B and then be allowed to read and write to the tags that exist on Gateway B. However, Gateway B will still handle things like writing to A PLC, alarms, and history for those tags. A Remote Tag Provider allows tags to be shared between gateways without the need for additional OPC connections, for a more streamlined flow of data. Before we get started, you'll first need to ensure that you have two separate gateways. In addition, you'll need to make sure both of these gateways are connected through the gateway network. You can see that I have one gateway installed locally and one installed on a remote machine here. Since we have our prerequisites set up, we'll go to the Configure section of the local gateway.

[01:07] Scroll down and go to Tags and Realtime, here on the left. If you already have some tag providers set up here, don't worry about it. Click the Create New Realtime Tag Provider link down below. Select the Remote Tag Provider option and go to the next page. Here we can see our remote gateway listed. If there were more gateways in our gateway network, they would also appear here, but since we only have the one, I'm going to make sure it's selected and hit the next button. This presents us with a list of the tag providers on that remote gateway. You'll notice that I only have the tag provider called Default and the tag provider called System. The System Provider includes all of the gateway's built-in system tags. Since the default tag provider holds the tags I'm trying to access, I'm going to choose default as my tag provider and click the next button. This last page is where we can customize exactly how this tag provider works.

[02:04] Since my remote gateway's name is Remote Gateway and the tag provider is default, it combined those elements to create this new name. If you'd prefer to use something different, you can change that to a custom name. And here you can see the gateway and provider sections got filled in automatically based on my choices from before. These are also customizable, if you'd like to use something else. 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. In this simple example, there are two gateways on the same network, and the tags we want to access from Gateway A, our local gateway, actually live on Gateway B, our remote gateway. If we set up a remote tag provider on Gateway A, it will request the tag information from Gateway B. B will query the records from its database, process the records, then send the results back over to the requesting gateway. 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.

[03:14] This graphic shows the flow of information directly from the database to the querying gateway, if database is selected instead of Gateway Network. When set to database, history requests will run against the database directly. In this scenario, the requesting gateway then processes the data. 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. Since we're not using the database for this demonstration, I'll keep the dropdown set to Gateway Network. I can also 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.

[04:04] If you click on the advanced properties checkbox, it will reveal some new properties that I'd like to draw attention to for just a moment. In version 8.1.34 of Ignition, the Enable Tag Reference Tracker Store option was added. This enables the storing of tag reference entries to a database on the local gateway for analysis in a designer. Its default value is true. In version 8.1.4, Allow Backfill Data became another new option. This is set to false by default so that each value is processed fully as it arrives, but if this is enabled, data will be allowed to arrive out of order from the source. Data from the past will be stored to history, but will not be used for alarms, scripts, or subscriptions. Once we have all of our options set, we can go ahead and click Create New Realtime Tag Provider. You can see that it is now created our new remote provider. Let's take a look at those tags in the designer.

[05:06] I already have a pair of designers open, one for my local gateway and one for my remote gateway. The first thing we need to do is make sure that Read-Write mode is enabled for both. 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. My local gateway doesn't have any native tags for the purposes of this demonstration. In the local gateway's designer, we can use this dropdown to select our remote tag provider. It has the same tags as the tag provider called Default in the Remote Gateway. If the value of this tag were to change in the remote gateway, you'll notice that it also updates on the remote tag provider on the local gateway. When you try to change a tag from the remote tag provider on the local gateway, though, you get an error message and it says Access Denied.

[06:03] This is because of the way I have my Service Security and Security Zones set up right now. This connection is read-only. To learn more about Service Security, please watch our Security Zones and Service Security video. You'll find a link in the resources below. Once I've set up security properly to allow Read-Write access, I can close this error and enter a new value into the tag on the remote tag provider in my local gateway. It also updates in the actual tag provider on my remote gateway. 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. The tags are going to be stored and executed from the remote gateway where the tags actually live and originate. If I create or delete a tag on this remote tag provider in my local gateway, that tag will actually be created or deleted on the provider that they originate from on the remote gateway.