Reference Library for Converting Between LabVIEW and XML Data (GXML)

[LabBEAN]

You need to name the wire coming out of the for loop:

Here's a snippet containing the Coerce to Type primitive.  Drag image to your desktop and then from desktop onto a LabVIEW diagram:

[Vikas23]

You can also use a shift register to obtain a label on that array (Attached).

[LabBEAN]

I can't view LV 2013 attachments, but I can imagine Vikas23 adding a shift register to the loop edge and wiring up the supporting build array.  If Coerce to Type is simpler and if you cannot find it in the palettes or with Quick Drop, courtesy of Jack:

[JackDunaway]

---

@LabBEAN wrote:

courtesy of Jack:

---

To give credit where credit's due, we can thank GregR for "releasing" this wonderful node into the wild. 🙂

Coerce to Type provides an essential ability, though not often required, that no other node offers.

[Paolo_Squillari]

Great job! Thank you!

In my application I can't modify the code inside the for loop because the unnamed wire comes from a LabVIEW subVI:

So I'll use LabBEAN's great solution.

I see now, for the first time, the Corce to Type from your snipped code. Where can I find this great function in LabVIEW (2013) palete?
I tried to locate it using the search, quick drop,... but is always missing (also the detailed help file).
Thank you again,
Paolo.

[LabBEAN]

The only way to access it has been the snippet I posted.  Sounds like it's still not in the palettes as of LV 2013.  Vote here if you'd like to see that changed.  😄

[LabBEAN]

If you'd prefer to use something you can find in the palettes / with Quick Drop, you can also use Variant to Data.  While just as effective, this code is not as readable since most don't know that VTD accepts other data types and wouldn't recognize what VTD is doing here.  Maybe add a comment if you use this method:

[Bob_Schor]

Found a bug (well, maybe it's a "Feature"), used really nifty "Coerce to Type" to demonstrate it.  I had a VI that output an Array of Strings through an Indicator (so I assumed that it had a valid GXML Name), but got error 537501 when I tried to write it to GXML.  I tried a simple Coerce to Type, naming the Array (again), but that didn't fix it.  The problem was not that the Array wasn't "named", but its elements (strings, in this case) weren't named.  The attached Snippet shows the Problem (here, I'm generating a "pure" unlabelled Array to illustrate the point) and the Solution (in the lower line, notice that I've labelled the string element "Oops").  

I went looking for the cause of this behavior, and think I found it.  The Generator calls Recursive Flatten to do the work of converting the Variant to an XML string.  It starts by getting Variant Info, including its name.  The Name is passed to Name Filter, which checks to see if the Name is "legal" (in the GXML sense).  The problem comes that simple types (such as Strings, I32, etc.) don't have "names" (unless you give them one using the Label and Coerce-to-Type trick), so an error results.

A solution would be to expand Name Filter, and pass it in both the Name and the Type Enum from the Variant Info function.  If the Name is blank (which is true for an ordinary Simple Type, such as an array element), replace the name with the Type Enum (using Format into String).

So I was wondering why the example that led to the Coerce-to-String didn't "break twice", once because the output array was unnamed, and a second time because it was an Array of an unnamed type.  The answer was that it was, in fact, an Array of Clusters, and the Cluster element had a name!

I'm going to port this change to Name Filter into my "slightly-modified" version of GXML, and will report back here if it really breaks things ...

Bob Schor

[Bob_Schor]

Works like a champ.  I modified Name Filter, passed the Type Info to Name Filter inside Recursive Flatten and Get Tag Contents (another place it is called).  I then ran the following "double-failure" code --

Note that the Array is unnamed, and the array elements are also unnamed (that's why I called it a Double Failure).  It generated the following GXML without error --

<GXML_Root>
  <Array dim='[4]' type='String'>
    <String>0</String>
    <String>1</String>
    <String>2</String>
    <String>3</String>
  </Array>
</GXML_Root>

Note that the unnamed Array is given the tag "Array", and the unnamed String inside the Array is given the tag "String".

I'll be the first to admit that, in general, you want to save named items in an XML file.  However, particularly in the case of Arrays, I see no reason why the array elements need to be given a Label -- it just frustrates the User and makes for extra (and, I believe, unnecessary) coding.  I'm prepared to be proven wrong ...

Bob Schor

P.S. -- the more I use GXML, the more I like it!

[Bob_Schor]

My October 18 post noted that you can make GXML type things itself (in certain conditions).  However, there's a second problem, which is that component names need to be unique.  Notice you have two unnamed clusters feeding into a third, which would result in the third cluster having elements named <Cluster> and <Cluster>, the same thing.  If you bundle all 5 elements into a single cluster, and use my revised GXML generator, you get the following XML output:

<GXML_Root>
  <Cluster mems='5'>
    <Transmit_High_Voltage type='U16'>1000</Transmit_High_Voltage>
    <Varilog_Var type='String'>My Test</Varilog_Var>
    <Burst_Number_of_Pulses type='U8'>5</Burst_Number_of_Pulses>
    <Varilog_Var2 type='String'>pioBurst</Varilog_Var2>
    <Boolean type='Bool'>TRUE</Boolean>
  </Cluster>
</GXML_Root>