Components

cancel
Showing results for 
Search instead for 
Did you mean: 

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

I would encourage you to make the modifications yourself.  My intention was to give the reference library enough framework and documentation that an end user could add features like this with minimal effort.

 

I am not in a position to develop new features in the near future but I am happy to answer any questions you may have about modifying the library.  The generation side of things would be pretty simple (like you pointed out though we would need some kind of look up table to preserve the input units in the XML string).

 

FYI I also looked at the LabVIEW flatten to XML and EasyXML but neither of them support numeric with units either.

 

Best Regards,

 

Jeff Tipps

Systems Engineer - Sound and Vibration 

0 Kudos
Message 11 of 132
(11,678 Views)
Does the Reference Library for Converting Between LabVIEW and XML Data (GXML) work under Linux?
0 Kudos
Message 12 of 132
(11,626 Views)

Hello,

 

I have not tested this on LabVIEW for Linux but the entire reference library is written in LabVIEW code.  The reference library uses native recursion (supported only on LV 2009) and leans very heavily on the library VariantType.lvlib found at \LabVIEW 2009\vi.lib\Utility\VariantDataType.  If this library exists then you should be in good shape.

 

Best Regards,

 

Jeff Tipps

Systems Engineer - Sound and Vibration

0 Kudos
Message 13 of 132
(11,620 Views)

Hi,

 

I'm exploring options to share data via XML between LabVIEW and other components for a new project. I'm experimenting with both the standard 'Flatten to XML' function and GXML.

 

The GXML-generated XML is more terse, and would be practically preferable, but I fail to understand two points:

 

  1. The statement made above in this thread, that "GXML will not parse any XML string, pretty much only XML strings created by GXML". It does seem that the GXML parser refuses to parse attributes that are not separated by CRLF (as such it is not an XML 1.0 compliant processor, see http://www.w3.org/TR/2008/REC-xml-20081126/#sec-line-ends), but why would one then choose XML at all to share data between LabVIEW and LabVIEW? There are plenty of (possibly more efficient) data serialization alternatives within LabVIEW.
  2.  

  3. Probably a consequence of (1): why, unlike the case of 'Flatten to XML', is the XML schema for GXML not published? 
    LVXMLSchema.xsd does specify all data just as plain xsd:strings, but at least provides the list of allowable data types and structures.

 

I'd vastly prefer not having to develop yet another custom VI to serialize LabVIEW data over XML, but the downsides of both "Flatten to XML" and GXML may leave no other viable option.

 

Francesco Prelz

INFN - Milan, Italy

Message 14 of 132
(11,494 Views)

Francesco,

 

Thank you for the feedback.  With this component it was my intention to make a more "terse" version of the LabVIEW Flatten to XML VI that was also supported on RT and that gave the user more flexbility regarding the structure of the parsing type definition.

 

  • I think you are right that the XML parser is not compliant to section 2.11 of the XML spec.  The parser does specifically looking for a #D#A and this appears to be an oversight on my part.  Please confirm for me, the specifcation is saying that the XML parser should be able to recognize three possibilities as an "end of line" character: #D#A, #D, or #A.  Am I reading this right?

There are more efficient (and in some cases much more efficient) ways of sharing data between LabVIEW and LabVIEW: some examples are flattened binary strings and the datalog binary format.  XML is slower than these optons but the upside is that it is human readable.  Furthermore XML is inherently hierarchical which is convenient for complex data structures like clusters of arrays of clusters, etc.  If you don't care about human readability then you are correct XML doesn't make as much sense.

I will return to the GXML source code and try to fix this in the near future but I would hope that instead of creating yet another custom VI from scratch that you could reuse what I have provided for you.  I included enough documentation in the source code so that users could make some modificiations themselves.

 

  • The target application for this reference library was LabVIEW to LabVIEW communication.  As such I documented the schema on the dev zone document from a LabVIEW perspective.  It includes all the supported datatypes and all the supported data structures (cluters, arrays, multidimensional arrays, clusters of multidimensional arrays, etc.)  I do see some value in making a more conventional XML spec but the time investment required didn't really line up with my intended use case.

 

Were there any other downsides to GXML that I have missed? 

 

Best Regards,

 

Jeff Tipps

Systems Engineer - Sound and Vibration

Message Edited by Jeff T. on 04-21-2010 10:09 AM
0 Kudos
Message 15 of 132
(11,483 Views)

Please confirm for me, the specifcation is saying that the XML parser should be able to recognize three possibilities
as an "end of line" character: #D#A, #D, or #A.  Am I reading this right?


The spec says that all combinations should be converted to linefeed (#A), which is in practice the same as saying that all those combinations represent valid end-of-line sequences.

 

This said, always according to the same spec (http://www.w3.org/TR/2008/REC-xml-20081126/#sec-element-content) the use of any whitespace in XML nodes that have 'element content' (i.e. they only contain other XML elements) is optional. So I believe that the parser should discard any particular combination of whitespace (including line feeds) when parsing the contained elements.

In other words, there should be no -required- line feeds separating the various attributes.

 

I'll take your suggestion to look at the source and see if it can be adapted as needed.

 

Thank you for your attention.

 

Francesco Prelz

INFN - Milan, Italy

0 Kudos
Message 16 of 132
(11,478 Views)

How do I use GXML to convert clusters that are bundled up programmatically?

 

That is, I have a large amount of clusters that get bundled up during runtime and later bundled together.   Is there a nice way to use GXML to convert them?  Unfortunately because they are bundled at runtime, the clusters do not have names and I get the error:

 

gxml_Builder.vi <ERR>Cluster item '' has an invalid name.  Each name must begin with a letter and subsequent characters may be letters, digits, a period, a dash, or an underscore.

See the attached for some sample code.  I would love to change the cluster name during runtime, but that's not allowed either.  I suppose I could set up individual cluster structures that I could later stuff as I get values, but that's a lot of work.

 

Any nice way to get this to work?   Example code would be great, as I'm still new at this.

 

Thanks

 

0 Kudos
Message 17 of 132
(11,271 Views)

I recommend making a type definition cluster and bundling your elements by name:

 

BundleByName.png

 

This way you have the ability to name the encapsulating datatypes. You will need a typedef anyway to parse the data in LabVIEW.

 

Regards,

 

Jeff Tipps

S&V Systems Engineer

Message 18 of 132
(11,253 Views)

Hi Jeff!

 

Thanks for the solution!   Yes, I'll do that.  I was hoping GXML could typedef and name everything itself (and be more flexible) but this certainly will work.

 

Thanks again,

0 Kudos
Message 19 of 132
(11,249 Views)

Is there a nice way to hack the VI   gxml_NameFilter to assign unique XML member names to unnamed LabView items?

 

For example, attached is my attempt to assign a unique name based on the time stamp that the subVI is called.  Unfortunately LabView seems to call this VI simultaneously for different items, giving the XML items non-unique names.

 

 <Item0634.7842 mems='2'>
  <Item0634.7842 mems='2'>
    <Transmit_High_Voltage type='U16'>140</Transmit_High_Voltage>
    <Verilog_Var type='String'>pioBurst</Verilog_Var>
  </Item0634.7842>
  <Item0634.7842 mems='3'>
    <Burst_Number_of_Pulses type='U8'>1</Burst_Number_of_Pulses>
    <Verilog_Var2 type='String'>pioBurst</Verilog_Var2>
    <Boolean type='Bool'>FALSE</Boolean>
  </Item0634.7842>
</Item0634.7842>

 

Thanks again,

0 Kudos
Message 20 of 132
(11,246 Views)