Alternative to Flatten to XML

[Jenso]

Hey guys,

I am currently looking for a way to simplify adding and removing new parameters to the config files of our test systems. Currently we are doing this with a self programmed XML library, that uses XPath expressions to read (and write) the parameters from an XML file. Adding new parameters is time consuming and thus I have tried to use the "Flatten to XML" and "Unflatten from XML" function.

That works quite well but there is a big downside compared to the old XPath method: If you add an parameter afterwards, e.g. with a software update, the already existing values cannot be read and all values from that config file will be replaced by the default values. Our test systems have to deal with roughly 200 article numbers, each having one or more testplans, consisting of 100 to 200 parameters each. And there are quite some of those test systems 8). So setting them up again will have a lot of people trying to kill me.

Ok, so basically I am looking for a quite automated way to save all different kinds of parameters (including clusters and clusters in clusters) in an XML file or the like without this downside.

By the way: I also tried "Flatten to JSON" which is able to preserve these values, but it is not able to deal with all kinds of input data types (although documentation asks me to wire anything). It was e.g. not possible to connect clusters that contain other clusters.

Do you have any suggestions?

Thanks a lot in advance...

[wiebe@CARYA]

Not sure why XPath takes a long time to add parameters. Not sure if it can be improved, as it sound pretty convenient to me...

I use ini files all the time. Not NI's library though, but my own. It can automatically populate a GUI with values from a file or vice versa.

You might as well use JSON, but not the build in flatten functions... The JSONtext library probably has all the flexibility you need.

[Jenso]

XPath itself does not take a long time, but all the wiring, converting enums to strings and back, placement of VIs, grouping into useful parent tags and all the rubbish around is a task that I always hate when it comes to adding a new parameter. But you are right, the effort is not that high. But the "Flatten to XML" function in comparison is extremely fast, because all you have to do is change the type def of the cluster that is used.

But it can also be, that I am simply slow

Thanks for your libraries example. That one is quite gorgeous. I will need to spend some time having a deeper look inside.

But it seems to look like JSONText is more suitable. I will have a try with it...

Thx!

[wiebe@CARYA]

---

@Jenso wrote:

XPath itself does not take a long time, but all the wiring, converting enums to strings and back, placement of VIs, grouping into useful parent tags and all the rubbish around is a task that I always hate when it comes to adding a new parameter. 

---

You can make a .vim for that. XML, XPath and type in, typed value out...

Enums are particularly tricky. If you store the strings, you're in trouble when the names change. If you store the integer value, your in trouble if you add items. You just can't win, unless you store all items and the selected item (string or integer).

Haven't gotten around making a .vim for my library. I started development in LV13, and .vim support wasn't there yet...

[Jenso]

Oh I did not hear about the *.vim files so far. They sound like a great solution for many of my problems. Unfortunately I am bound to work with Labview 2014 and it seems as if that filetype has been firstly introduced in LV2017...

Bad luck...

About the enums: You are so right. I have chosen the string-storage version, in that case I can at least detect if there is something wrong. But that way I lose anyway - just as you say 😎

[wiebe@CARYA]

---

@Jenso wrote:

Oh I did not hear about the *.vim files so far. They sound like a great solution for many of my problems. Unfortunately I am bound to work with Labview 2014 and it seems as if that filetype has been firstly introduced in LV2017...

---

You can make subVIs for every base type. String, I32, Boolean, timestamp maybe (but very tricky), more is usually not needed.

For enums, you can probably use a variant in and a variant out. Then, you only need to cast the variant to the enum...

You could even put these VIs in a Polymorphic VI. It's a bunch of duplicate code (all the VIs are mostly the same) but the result is a VI that's pretty easy to use.

[Jenso]

That is basically the way I am doing it right now. I have several VIs for each datatype, except enums and seldom other types like arrays of unusual types.They are combined by a polymorphic VI that adapts the source (where possible). But still I have to wire each one to a cluster, arrange the wires, create an XPath and so on. That sounds like no work, but when creating new subroutines and test steps for the test system, this action is really annoying me.

I know it sounds greedy, but I wanted more. When I saw the flatten to XML functions, there was absolutely no configuration necessary anymore.

But anyway it is good to hear that most of you guys are basically using the same method, so I am totally wrong...

[wiebe@CARYA]

I usually end up doing these things by reference.

Get all control\indicator references (VI Server), and use the label to lookup the value. Use the reference to get\set the value.

Not sure if JSONtext has this, my ini file library does. It's not that easy to make, as you need to support different types (including nested types like clusters), but it might be worth the investment.

[Jenso]

Thanks for the hint. I think I will give it a try that way...