Your load function is replacing the CONVERSIONS top level object by assigning to it. Don't replace it. Assign into it. (Perhaps use the .update() method.)
Be aware that your variable is per leaf project, not global. All leaf projects that will use this need to call load() in their gateway startup script.
(Note, you should use system.util.jsonDecode() instead of jython's json module.)
OK. I’ve replaced
CONVERSIONS = data
with
CONVERSIONS.update(data)
EDIT: For whatever reason, I can’t get CONVERSIONS to reliably retain any data.
EDIT #2: I might have this right. I had that script running as a Gateway startup script. I moved it to be a session startup script. I hope that’s not going to bite me later, but I don’t see why it would. That seems to have loaded the values ok. I’ll keep testing.
EDIT #3: I prematurely celebrated. After taking out all my debug stuff it stopped working.. Sigh
I feel like the larger problem will be the historian trying to pull in data in the proper units. Personally if there's only ever going to be 2 units between imperial and metric (and no 3rd option), I'd almost modify your UDTs to have the I/O tags being imperial in your case and a second tag with the metric converted value using an expression tag and historize both. For example FT_1234.FlowImperial and FT_1234.FlowMetric or something similar. Then your tagging would all be indirect with a session property string that has "Imperial" or "Metric" that gets to be part of your indirect tagging. When it comes to historizing if they're using the tag picker, the user can pick which set of units they want to use. Yes, this takes some extra storage on the historian, but storage is cheap anymore.
Cough. I talked him out of that already.
Doubling one's DB load just for this is ridiculous, IMNSHO.
How would you propose handling tag history then if they want to be able to historize in either/or/both units?
You don't. You historize each point in the units the device supplies. Do unit conversions at point of display. Yeah, the PowerChart cannot do this, but serious people don't use it anyways.
Linking a previous post:
The expression transform will be more performant. The dataset should be very maintainable, straightforward to update and maintain….no scripting required.
Unless you’re using Ignition Edge. I have yet to find a good charting option that will work with it. As you know, Edge is not compatible with most 3rd party modules. That’s become a pain point in all of this for me. One of the features of the Power Chart is the ability to programmatically “push” an X-trace, which cannot be done on the time series chart. I have it set up where there’s an event log table in a docked view the user can pop out, click on an event, and the chart will automatically zoom to that point in time, displaying an x-trace at the time stamp. Clicking the chart triggers a message with that record’s timestamp as the payload, and the chart responds to it by adjusting itself to what it needs to show. The customer loves this and is not willing to give it up. At this point they’re even willing to just lock the chart to being in native units only for now until a better solution comes along.
I’m not using the Power Chart because I’m not serious. It’s literally the only thing I’m aware of that can give my customer what they want with the tools I’ve been given.
One of the key things I try to do with all of our standards is to make sure anything I build is compatible with both Standard and Edge editions because we do so much of both. Granted there will always be things that aren't (like diagnostics for databases), but in general I try to make as much as possible work for either version without modification.