8.1.38 Vision
Maybe I'm using the Tag Provider wrong, but it's breaking my historical trends and sparklines.
I have a project that encompasses several PLCs. Each PLC is under a different developer, so for organization purposes, we have a tag provider for each OPC link to a PLC. Of course some HMIs will cover multiple PLCs and hence use multiple tag providers. Within the development of a project I often switch the project between the default tag provider for quicker drag/drop tag access into elements, historical trends, sparklines, etc.
Not realizing it, I noticed today that doing so breaks my trends. It seems when the DB pick list is presented and you select a tag, if you select it from the currently default provider, it only appends the [Database name] to the tag path. But if you select a tag from another tag provider, it appends the [Database name/Gateway name:Tag Provider] to the path.
So if during development, I'm switching project default provider, it breaks all the trends.
The Database name is the database name. For what purpose is it appending the gateway name and tag provider to the path for historian? The other issue is on deployment, depending on the customer, gateway names are often changed. So even another opportunity for broken paths. I understand the limitations due to gateway name changes, but these are not distributed systems with multiple gateways, so managing name changes hasn't been an issue. But this default tag provider wrinkle is new to me.
History providers, due to interactions with gateway networks and remote providers and diversion of queries, have a more complex naming scheme.
Where you show "Database name" is really the history provider name--it's just that all databases have an associated standard historian. You can add other historian types with custom names.
The gateway name, known as the "driver" in qualified path documentation, is needed to distinguish source gateways when multiple gateways with same-named tag providers push to a database cluster (or via replication).
When you are working with multiple tag providers within a highly parameterized project, consider not setting a default tag provider, or using an empty one as your default during development. Then the designer will always fully-qualify tag and history paths during drag-and-drop.
1 Like
So behind the scenes, Ignition is using the default tag provider selected in the project to construct the path to the historian? Seems oddly hidden. Would be better, IMO, to always include that construct in the historical binding in the various widgets, so at least it's very apparent the path and it wouldn't matter which default tag provider was selected. I could see where it was considered a feature for a singular tag path in a project (default), but it's a bit confusing with multiples. When I started ignition a year ago, I had a client that complained that sometimes their history tags wouldn't work. Now I bet I know why. I'll need to clue them in 
Edit: Your non selection of a tag provider during development is a good one, but then what is the purpose of having a default provider at all? What advantage does it add?
In simple applications with one gateway, one tag provider, and no gateway network, the current behavior is a big win.
But it is insufficient for anything else. Changing the behavior would be a regression for the simple case. (The quite common simple case.)
"One Tag Provider" would be the defacto default anyway, no? In otherwords, removing a selection of Project default Tag Provider wouldn't change anything for the general case, and would eliminate confusion for multiple tag providers. My opinion of course, but it just seems more intuitive to not have it.
Anyway, thanks as always for the rapid response. Your help is always appreciated!!