Hi guys,
I would like to create various multi-state buttons per window that allows the user to switch between different engineering units and am wondering if/how anyone has implemented this elegantly.
Do you create a tag for each different unit?
How do you make it so that if 2 or more vision clients are running the same window, that 1 person doesn't change another person's units?
Regards,
D.Botha
You could create a tag for each unit then use indirect tag binding to determine which one you wanted. You also could create tags in one unit, then depending on maybe what check box is selected just convert the standard unit to the one wanted. It really depends on how your client is setup, number of tags, etc. on which way to go.
Each client is independent of each other, so any conversions inside the client won’t affect another, as long as you are not writing to tags. If you do write to tags, then you’ll setup them up as client tags so they are individual to each client. this is a vague answer. More information on your situation will help narrow advice down.
I’d like to resurrect this topic because it doesn’t get enough attention.
We’re going through a painful process where we have to change what we’re doing because the original method I devised is using a lot of data and a lot of bandwidth. I originally made a UDT for process data that had elements like “currentValue” “gaugeMin” “gaugeMax” etc. So in the UDTs I created an “Imperial” folder and a “Metric” folder. The Imperial folder contained the “real” tags and the Metric folder contained Derived tags. It seemed like a convenient method at the time because Derived tags convert bidirectionally, so it made things like setpoints and alarm thresholds easy because all I had to do was point to the Derived tag and it would convert the value before sending it on to the PLC program (which was written in imperial units and I did not have access or permission to change it). I set up a session property that had a value of either “Imperial” or “Metric,” and used that to set up indirect bindings on my templates. I did have to historize both the Imperial and Metric tags to get my PowerChart trends to work. But, originally my scope was to create an Ignition Edge app to replace a Panelview Plus, so at the time I thought the extra storage space requirement was an acceptable downside.
Fast forward to now where the project has grown into a platform with version control, cloud versions of the app, database connectivity, MQTT, etc. Things that were always in the works but not really hashed out yet when I made these decisions. Now, that extra process data adds up in terms of cellular data usage, and database storage. I had a solution that worked well for a standalone Edge application, but the bottom line is, it didn’t scale. So, here’s my plan moving forward and here’s how I’m planning on handling unit conversion in Ignition in the future:
First and foremost, unit conversions will be done at the visualization layer only. Not in the PLC, not in a database, not in tags. Process data will always only be stored in one unit system and only one unit system. Things like reports and trends will utilize scripting to present their data in other units. All unit conversions will be done with centralized scripting, so there is always a single source of truth and a single place to add or modify conversions as needed. The one downside is that you cannot use Perspective Powercharts with this method. There is no way to dynamically convert data in a PowerChart that I have been able to find. It only seems to present the data in the form it exists in the historian database. Instead, I’ll be switching to time series charts and utilizing script transforms to iterate through the dataset if it needs to be converted.
Not a serious loss. You should be using Embr charts anyways.
I tried to install the module on Ignition Edge, but it errors out and says not valid on Ignition Edge unless licensed. But I thought the license was free?
Oooops. Sorry. Only a limited set of 3rd party modules are available on Edge at all, and none that are open source.
From your description of the growth of your system, I would expect you to not be using Edge for the bigger tasks.
We still need to use Edge. The Edge application is for the local stations. They want a “mirror” of the edge application on the Cloud as well, so at this point we have a cloud server where we use the EAM to keep resources synchronized between the two. Edge apps send their data via MQTT. Cloud tags are a child of the main UDT but all overridden to be reference tags pointed to the MQTT namespace instead of the OPC paths like they are locally. So all the views and their bindings are designed to work in both the Cloud and Edge environments. That does limit us, but the OEM selling these stations doesn’t want to pay for a full Ignition license for every station. So we work around where we can. And if we can’t do something because of it, we let them know and they figure out if they really, really need that feature enough to justify the cost or not.
I know it doesn't help now, but powerchart / charting is like... the main? focus for the Perspective team for the next major version of Ignition. Using echarts I think.
Do you mean the next update to 8.3 or the next major update? We’re considering our upgrade path right now.
The next major update, which is why it doesn't help now.
