02-09-2010 09:42 AM
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
03-01-2010 02:06 PM
03-01-2010 04:36 PM
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
04-21-2010 03:24 AM
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:
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
04-21-2010 10:06 AM - edited 04-21-2010 10:09 AM
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.
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.
Were there any other downsides to GXML that I have missed?
Best Regards,
Jeff Tipps
Systems Engineer - Sound and Vibration
04-21-2010 11:13 AM
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
06-10-2010 07:40 PM
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
06-11-2010 11:37 AM
I recommend making a type definition cluster and bundling your elements by name:
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
06-11-2010 12:49 PM
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,
06-11-2010 01:09 PM
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,