Hi folks,
We have a instance of Ignition collecting data from OPC servers and recording history both locally and on another Ignition instance in the cloud.
A question came up regarding the engineering units of the tags. Users are able to change the engineering units on local site depending on available sensors.
The problem we are encountering is how to reflect any changes to tags engineering units to the Ignition on the cloud.
From what have seen sqlth_* tables have no record of the tags attributes. So if user changes the source tag the cloud will not be aware of change.
Is this statement correct?
Alternatively, we are thinking of using external tag provider or have script that records the engineering units of each internal tag on an interval . Any time it changes it will record this change locally/cloud in SQL table.
Would this we good way to approach this issue?
Appreciate any thoughts and thanks in advanced
Are these configured as completely independent servers, or are you using the Ignition network and fallback structure?
In case of independent servers, is it possible to make your own interface to create the tags?
Tags can be created inside Ignition with the system.tag.addTag function: https://support.inductiveautomation.com/usermanuals/ignition/index.html?system_tag_addtag.htm
Together with some OPC browsing, you can create a complete interface to make new tags.
The advantage of this is that you limit the users to work in a field you completely control, so it’s easier to catch all oddities you didn’t think about (f.e. only allow OPC and memory tags but don’t support expression, SQL or other tags). You also know about the changes immediately.
I wouldn’t advise browsing in the SQL database, as that’s very undocumented, and undocumented features can be changed without prior notification. So even if it works now, it might stop working in the future.
The other alternative is indeed to browse through the tags periodically, which can also be done with documented functions. But you’ll have to catch quite some different configuration possibilities if you want to support all tag types (and it’s different to tell users what tag types are supported and what types aren’t).
But that’s all in case when the gateways are configured independently. If you use the fallback network, it’s probably automatic or at least easier. But I don’t have a lot of experience with fallback setup.
Hi Sanderd17,
At the moment we are in development so nothing is set in stone:
"Are these configured as completely independent servers, or are you using the Ignition network and fallback structure?"
They are connected via gateway network, down the road it would be hub and spoke setup with multiple Independent servers (that are mobile) sending historical data to a central server over satellite connection.
So yes, they are independent in sense they do not rely on each other to fully function
"Tags can be created inside Ignition with the system.tag.addTag function:"
I have used this function before but am not sure if it can be used in this case; unless I am misunderstanding something.
Users would not be creating any new tags as these are always the same. What does change is the tag attribute=‘engineering units’.
Sounds like browsing the tags attributes periodically may be best method since users should not be adding new tags and only changing the attributes of existing tags.