Control (by reference) to string -> custom "flatten to XML"

[cober]

I'd like to do something similar to "Flatten to XML" just with more control how the output will be formated (e. g. using the caption/tip strip/description values in the output). I don't need every possible data type to be handled, but it should be able to deal with strings, numbers, arrays, clusters (and arrays thereof) and enums.

The control to be "flattened" will be given to a subVI as a generic control reference. By reading the classname, a case structure handles the different classes. Strings and clusters are simple (for clusters recusively call the function for every element in the "controls[]" property). Numbers already are a little bit tricky since I can't seem to get the representation of them from the reference (the classname is "Digital" for all of them and the value is a variant), so all numbers appear as floating points in the strings, even the integers.

But where I'm really stuck is arrays. I just get a single variant out of the value property after casting the control reference to an array reference. That's expected, since I don't cast to a strict class. And although I can get a reference to an array element, this is only a reference to the first element of the array. I found no way to "walk" through the elements.

Is there any way to get the reference to every array element so I can recursivly apply my function?

[paul_a_cardinale]

Not what you asked for, but you may be able to use some of the code in this.

[HeinzG.]

Hi cober,

could you give me some more hints on what you're trying to accomplish?

1. What is your main task?

2. Did you try to work with Typedefs?

3. Do you need to use references and property nodes?

4. Could ou create and post a simple example, describing your problem?

Kind regards

Heinz

[cober]

The idea is to convert something like this

into somthing like this

<dataset>
	<timestamp>123456789</timestamp>
	<stationid>2</stationid>
	<sensorvalues>
		<list>
			<name>channel a</name>
			<displayname>caption text here</displayname>
			<description>description text here</description>
			<float>
				<name></name>
				<unit>V</unit>
				<value>3.46</value>
				<value>3.32</value>
				<value>3.21</value>
			</float>
		</list>
		<set>
			<name>events</name>
			<displayname>caption text here</displayname>
			<int>
				<name>interrupt count</name>
				<displayname>caption text here</displayname>
				<value>5</value>
			</int>
			<string>
				<name>sensor raw</name>
				<value></value>
			</string>
		</set>
	</sensorvalues>
</dataset>

The real universality starts within "sensorvalues". There will be different "sensorvalue" clusters (they could be typedef'd), but I don't want to write a "to String" function for every one of them. As I said, it should be something like "flatten to XML" (which accepts any data type), except I'd like to have more control what appears in the output.

I need the property-nodes, because it contains the caption/description/tipstrip that should be included in the XML.

[HeinzG.]

Hey cober,

"what accepts any datatype like flatten to xml" is a polymorphic VI. File>>New...>>Polymorphic VI. Also see the LabVIEW-Help "Building Polymorphic VIs".

Another question:

Needs the cluster "sensor values" to have different data types or do you just want to change its look?

regards

[cober]

A polymorphic VI is exactly what I do NOT want to have to do: create the logic for every kind of datatype there is. "Flatten to XML" works differently, it isn't even a polymorphic VI in that sense, because it accepts every data type you can think of and there isn't one "morph" for every one of them.

The example given is just the general idea, not the "real" data. There will be several remote sensor stations that wirelessly report to a central station. The (environmental) sensors can be very different on every station and creating a "common" datastructure will possibly create a mega cluster, where each of the stations will only use a small part of it. The central station will send the datasets over the network to another program (no longer Labview) and XML is the easiest format to transmit the data (no worries about byte order, descriptive, almost human readable, parsers available, aso...). Most probably at no point will anbody ever see any of the Labview frontpanels on screen (except for debugging).

(btw nudge, nudge NI: can we have blockdiagram only VIs, please? In 9 out of 10 of my cases the only use for the frontpanel is changing the connector pane, but I still get an additional window cluttering the taskbar)

[tst]

What you basically want is to recursively parse the data out of the cluster. I won't give you a ready made piece of code you can use, but I will point you to some relevant resources:

1. JKI has the EasyXML toolkit, which does exactly what you want. The main problem with it is that the code is locked, so you won't be able to customize it (although you might be able to give it a specific schema or post process its output). It might also be for pay.
2. This will show you the general concept of recusively parsing the data from the cluster - http://forums.ni.com/t5/LabVIEW/Nugget-Using-control-references/m-p/570756#M267659
3. Likewise, MGI's read-write anything VIs will do the same. They use the variant parsing VIs which can be found in <LabVIEW>\vi.lib\Utility\VariantDataType.

At least the last two should give you an actual idea of what's required.

[Todd_Lesher]

Here's another good example:

http://lavag.org/topic/16217-cr-json-labview/?hl=json

[cober]

Hmm, didn't think this would grow to such extents. I've looked at the vi.lib functions before, and while there's a method to get information about an array, there's still no easy way to get the length of an array and iterate through the elements of it (wouldn't even mind if the output would be the elements just as a variant). As I see from the examples you got to calculate offsets within a variant to get elements aso... Until I get my head around this I could write many custom "flatten to XML" functions.

I guess this time I'll just "forbid" Arrays. If a list of values will be needed, it will have to be a cluster with a huge amount of elements (256 is the limit per cluster it seems). It's not pretty, but there wouldn't be Arrays with thousands of elements anyway.