How do I query a remote tag historian?

Ignition
1

I have two servers connected via the gateway network. My production server has all of the tags configured, with history recorded to the process database. I’ve configured the production server to be a remote realtime and remote history provider through the gateway network to my dev server. I can query the realtime tags with no issue, but I cannot get the history query to work. Here’s what I’m trying to execute from the dev server Designer:

newValues = system.tag.queryTagCalculations(
paths=[’[IGN_PROD_Process]B1Line/AutoStacker/Weight/DivertedWeight’],
calculations=[‘Minimum’,‘LastValue’],
startDate = “2017-09-18 07:00:00”,
endDate = “2017-09-18 15:00:00”
)
totalEnd = newValues.getValueAt(0,2)
totalStart = newValues.getValueAt(0,1)

I’m getting values of ‘None’ back for the newValues, but if I query it on my prod system, I get results. Any suggestions?

2

Try a fully qualified tag path; eg:
[<database name>/<gateway name>:<tag provider>]path/to/tag
Where DB is the name of the current gateway’s connection to the database, and gateway name is the name of the system actual storing data into historian.

1 Like
3

My DEV gateway does not have a connection the database on the PROD system. My understanding of the Gateway Network functionality is that I can have read-only access to the historian on PROD from DEV, without any further set up.

Here’s the process I followed:

  1. In my PROD system, I established an outgoing connection to DEV
  2. In DEV, I configured a “Remote Tag Provider (Gateway Network)” for live tag views, which works fully.
  3. In DEV, I configured a “Remote History Provider” which is showing as a ‘Read-only’ status right now (which I think is correct)

But I’m not getting any values from my tag history query.

4

Is [IGN_PROD_Process] the name of the remote historical provider? Or just the realtime provider on the production system? Try the name of the remote historical provider connection (from the dev system) in square brackets.

5

Correct, ‘IGN_PROD_Process’ is the name of the remote historical provider on my DEV gateway.

6

Just mocked this up; my earlier thought was correct I just gave the wrong definitions. Use IGN_PROD_Process as the first value of the qualified path:
[IGN_PROD_Process/PROD Gateway:default]path/to/tag

Just verified that this works on a remote historical provider with no DB access.

7

Okay, that didn’t work for me - let me make sure I have everything correct…

[IGN_PROD_Process/PROD Gateway:default]path/to/tag

Can you help me understand where that PROD is representing? Is that the database where PROD historian data is stored?

Also, can you explain what the ‘Gateway:default’ piece does? Is that specifying a which Gateway I’m trying to choose the data source from?

8

The qualified path needs to be:
[ historical provider name (IGN_PROD_Process, in your case)
/ name of the gateway actually storing history
: realtime tag provider name of actual tag with history
]

So you’ll need to change PROD Gateway and possibly default from my example.

9

Okay - I’m wondering if there is something deeper going on. I restarted my designer (when all else fails…) and then tried to run my test script in the Script Console. The live values didn’t start reading from the remote gateway until I had extended the tree inside the designer, and the history values are still not reading. But I’m noticing in the log files that I’m getting an ‘Unhandled Intent Failure’ error coupled with a ‘[IGN_PROD_default] Subscription path model set detected to be out of sync. Will re-synchronize’ warning every 10 seconds now. Note that IGN_PROD_default is the Realtime Remote Tag Provider.

Any thoughts on these errors, and are they related?

10

Unhandled intent error is a little vague - what version of Ignition are you using on both sides?

11

PROD is 7.9.1, DEV is 7.9.0.

I can post full stack trace if you want, top line is:
java.io.InvalidClassException: com.inductiveautomation.ignition.common.sqltags.model.scripts.BasicTagEventScripts; local class incompatible: stream classdesc serialVersionUID = 5696100467529495443, local class serialVersionUID = -3863182802171005730

12

I’d get them both on the same minor version. 7.9.0, 7.9.1, and 7.9.2 all have slightly different versions of the same basic messages as we refined the protocols used for GAN communication.

13

Will do - in the interim, the Prod log file is showing this error message:
[_0:0:ignition-DEV_tagsubupd_ignition-PROD_default:958] Error delivering subscription updates. The remote gateway may not be available, or the session may be expired. Turn this logger to debug for full error information.

14

Alright, updating the minor version seemed to help with that error. I can now at least get an error registering on the PROD gateway now:

No historical tag information could be found for any of the specified paths. Check that paths are correct. Paths: [b1line/autostacker/weight/totalizedweight]

So at least DEV is querying PROD, even though I know for a fact that path exists (different capitalization, but that seems to be internal to Ignition).

In the PROD script console, this works:
newValues = system.tag.queryTagCalculations(
paths=[’[Process]B1Line/AutoStacker/Weight/TotalizedWeight’],
calculations=[‘Minimum’,‘LastValue’],
startDate = “2017-09-19 07:00:00”,
endDate = “2017-09-19 15:00:00”
)

In the DEV script console, this is causing the above error:
newValues = system.tag.queryTagCalculations(
paths=[’[IGN_PROD_Process/PROD:Process]B1Line/AutoStacker/Weight/TotalizedWeight’],
calculations=[‘Minimum’,‘LastValue’],
startDate = “2017-09-19 07:00:00”,
endDate = “2017-09-19 15:00:00”
)

15

It would probably be worth upgrading both systems to 7.9.4 before going much further with troubleshooting; it’s definitely possible this is a bug we’ve already taken care of.

16

I’ll try to get a second server setup… people get touchy about updating production servers for some reason. Thanks for the help!

17

@tim.schultz. Did matching the minor revision between the two gateways resolve this issue? I also have an ‘Unhandled Intent’ error flooding the logs that I think might be related to remote tag provider communications.

18

Hey Tony - I believe that it did, as we ended up with all gateways on a later version (the dev server mentioned here is still on 7.9.9, so not even too much newer).

19

Thank you for the feedback, Tim. I have one gateway version 7.9.4, the other 7.9.14. It looks like there was a change to the GAN communications between the minor revisions that affected the alarm data. For this implementation, the alarms for the remote tag provider were not necessary, so we were able to disable the alarms on the remote tag provider to resolve the issue for now. I think upgrading the gateway to the same minor revision is going to happen in the near future.