LabVIEW
Merge clusters with overrides
Solved!
Thanks for the lot of ideas. I have tested @PhillipDBrooks’ solution, and it seems that it will work for me, keeping in mind that converting to string and back is not a cheap thing.
With this solution, I like that it can be loaded back even when the order of the items in the enum is different from before.
@Andrey_Dmitriev: you are totally right. I need this because I am loading settings from before, and I have to maintain backward compatibility.
@paul_a_cardinale: Currently, the Xnode solution doesn’t work for me, but it would be quite elegant.
Keep in mind that the conversion to string using the JSONText library does NOT preserve bit-by-bit values for single precision numbers. It's quite good, but for your example you need bit-perfect values, which this does NOT have. The author has a bit of discussion on this here:
https://bitbucket.org/drjdpowell/jsontext/issues/13/ni-json-number-of-digits-bug
Example:
For some values of floats you do get perfect retransmission, but for arbitrary "it's not actually a float it's a bitfield" values you will NOT get what you need, and it'll fail randomly depending on what your original bitfield was!
You may be able to make a custom serializer to do this, or maybe you could make some sort of pre-processing function that takes Floats and flattens them to a U8 array or string, then go to JSON and back, but that seems like a lot of work to avoid rearchitecting something into "the right way" (which is to store bitstreams as either a string or U8 array). It sounds like you're not using typedefs, which sucks, but going through it once will take a while... but fixing the bugs from this decision will likely bite you in the long run. Nobody here can make that call for you though... I'm sure we've all been in the "just get it going you don't have budget to fix it" spot before 🙂
Here's the fix. Just replace the one VI (located in ,,, \Support\Merge Clusters).
Not really the proper way to make changes to an XNode, but as long as you first delete all the instances of the XNode on BDs, it should be OK.
(The problem was a race condition inside a property node.
Needs to be this: , not this:
)
I have had a need for something similar to this in the past, but I just ended up writing a normal VI with type def clusters so it wasn't reusable. In my case I had a cluster with a set of limits in it. It was things like "Maximum Allowed Voltage", "Minimum Allowed Voltage", "Maximum Allowed Current", "Minimum Allowed Current" etc. This cluster would be settings that the "System" could support. The system might support 0V to 1000V range. Then we would have the limits that the DUT would want, so it would have it's own set of "Maximum Allowed Voltage", and "Minimum Allowed Voltage" which could be more restrictive like 20V to 80V. The "System" would have a cluster of limits, and the "DUT" would have the same type def cluster of limits that could be more, or less restrictive. The VI I made needed to merge these two clusters finding the most restrictive set of limits. If a limit was NaN then it wouldn't add any restriction on the existing limit. There was also a third cluster set for the "Sequence" being ran. It could have a "Maximum Allowed Voltage" which would need to be merged with the existing limits. In practice the "Sequence" limits were usually NaN using whatever limits the System and DUT came up with.
Sorry for such a long explanation. All of that is to say I could see an XNode of this type, or a similar kind, being useful in the past for merging sets of limits from various sources.
