Components

cancel
Showing results for 
Search instead for 
Did you mean: 

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

How can I modify "Search Parser.vi" to skip missing items in XML string?


I usually store configuration info in a typedef cluster and write it to a XML file; I would like to change cluster type definition and be able to retrieve part of the previous configuration by loading default values (empty string for string, 0 for DBL etc..) for missing items.

 

 

Thank you

0 Kudos
Message 121 of 132
(3,251 Views)

Sorry, I haven't been here in a while, and missed your post.

 

I use XML instead of .ini files for my Configuration data.  One such file contains Device Configuration information for analog and digital signals that I am sampling.  Parameters include the Sample Rate (I32, default 1000), the "names" of the Analog channels I am sampling (the first name is assigned to A/D 0, and the channels are assigned sequentially, with as many channels as I have names), the "scale factors" (in my case, "Units/volt") for each channel, the names of the Digital channels I am sampling, and their Units/Count scale factor.

 

In my LabVIEW program, I bundle all of these values into a Device Config cluster, with elements Sample Rate (I32), Analog Names (Array of String), Units/Volt (Array of Dbl), Digital Names (Array of String), and Units/Count (Array of Dbl).  These get written to an XML file, DevCon.XML.

 

To edit this file, I basically do not try to edit the XML file.  Instead, I open the File, read/parse it to get the Device Configuration cluster (parsing is simple, as this is the only thing in the file), then edit the LabVIEW cluster as I wish.  I actually wrote a Utility to do this -- it simply displays the Cluster as a Front Panel Control (which can be edited), then when I push "OK", it simply recreates the XML file, overwriting the previous Configuration (I also have the option to save with another filename, instead).

 

I use GXML, but this idea would work equally well with any XML file (or even with a .INI file).  The key idea is to not worry about the file format -- use it to read all the data, manipulate the data using familiar LabVIEW tools, then (re-)write the file.

 

Bob Schor

0 Kudos
Message 122 of 132
(3,234 Views)

I believe there is an example of using the GXML "Version" string to show you how to do that.  Look in the Examples folder for GXML Versioning.

 

Bob Schor

0 Kudos
Message 123 of 132
(3,234 Views)

P.S. -- my longer post, today, about Configuration Files was a response to TShelleyamrc, and the short, second post was a response to OriginalP.  I probably should have quoted them ...

 

BS

0 Kudos
Message 124 of 132
(3,232 Views)

Some New Thoughts on GXML.

 

I've been using (and "ab"using) GXML very successfully for about two years.  I have a Data Acquisition Project that runs an Experiment consisting of multiple Trials -- indeed, the Experimental Paradigm is governed by an Excel Workbook, with an Experiment Worksheet holding about 30-40 parameters that are "constant" during the Experiment and a Trials Worksheet having multiple (perhaps 150) rows representing individual Trials, and having around 120 columns representing the possible parameters that determine the settings for that Trial.

 

We collect two kinds of data -- sampled Analog and Digital data, typically 16-24 channels at 1KHz, and "Event" data, such as the changing of a Digital I/O port, or a Message being sent between the Host PC and the RT Target.  Sampled data is characterized by a fixed format (in our case, I16 values in what is effectively a, say, N rows by 16 column array) coming in at very regular intervals (one row/millisecond) and a "variable format" (depending on the kind of Event) coming in asynchronously, but where the time of the Event is a critical part of the data.  In addition to this, we need to record Experiment-specific and Trial-specific information so we can interpret the data from the Experiment.

 

I decided on a 3-file data format.  A Header File was written in GXML, the initial part of which described Experiment-wide parameters, such as the Date and Time of the Experiment and the settings (obtained from a Configuration File) used to define the Data Channels, and the final entries, one per Trial, consisted of a LabVIEW Cluster with all of the Excel Variables used to define that particular Trial.  A second, Event, File was also written using GXML (mainly for ease of User Viewing).  This consists of an XML record for each Event, stored (in LabVIEW) as a 3-element Cluster of Event Time (a U32, milliseconds since the Start of Experiment), Event ID (e.g. Message, Digital In, RT Action) stored as an Enum U16, and the Event Data, stored as a String.  Finally, the final Samples file was simply a binary file of I16 integers representing multiple samples across a fixed number of data channels (the Data Channels being defined in the Header File, and each Trial entry in the Header File having a pointer to the sample number that start that Trial's Sample Data).

 

This works very well, is easy to use (with a few "extensions" to GXML that I added), and pretty fast (it took less than 20 seconds to get all the Header and Event data for an Experiment with 144 Trials and more than 8000 Events to be parsed into Header information, including an array of Trial Cluster data, and an array of Events).  But there were two related items that bother me.

 

First is an XML Rule that XML Tags cannot contain spaces, yet GXML uses the LabVIEW Variable name for the Tag.  For example, my Event type is a Cluster with elements "Event Time", "Event ID", and "Event Data", all of which contain spaces.  The solution that GXML adopts (not a bad one!) is to replace the spaces with underscores, creating the Tags "Event_Time", "Event_ID", and "Event_Data".  As it turns out, there are other symbols that I've used in LabVIEW names that are also not legal in Tags, such as "#", so my version of the GXML Name Filter has some additional steps.  Problems can also arise when you need to recover the LabVIEW name from its GXML-transformed version -- does that underscore always mean a space?  [Answer -- the Shadow Knows .....].

 

A related problem comes if you want to put a constant (instead of a LabVIEW Variable) into a GXML File.  GXML takes its Tag from the Label, and the typical Constant has no label.  There are ways around this, as well, but it's one more thing to fret about.

 

How to Have Your Cake (keep the "lean and readable" form of GXML) and Eat It, Too?  As I was trying to learn more about the Rules of XML, I noticed that while Tag Names have Rules, there is no Rule for an Attribute except that it must be enclosed in Quotes.

 

Here is an example of an Event cluster in GXML:

 

<Event mems='3'>

<Event_Time type='U32'>0</Event_Time>
<Event_ID type='Enum U16' sel='UI Msg'>0</Event_ID>
<Event_Data type='String'>Choose XL File</Event_Data>

</Event>

 

The Attribute "mems" tells GXML this is a Cluster, described by the entries that follow.  The form of the individual Entry is a Tag that includes the LabVIEW Name of the element (with spaces replaced with underscores), an Attribute "type" that gives the LabVIEW Type of the Cluster Element (and, in the case of the Enum U16, gives the "Enum name" of the Value), the Value, and the End Tag.  How would this look if we switched Tag and Type?

 

<Cluster name='Event' mems='3'>

<U32 name='Event Time'>0</U32>
<Enum_U16 name='Event ID' sel='UI Msg'>0</Enum_U16>
<String name='Event Data'>Choose XL File</String>

</Cluster>

 

 

Notice the names now have no XML-imposed restrictions on legal characters, hence can contain embedded spaces.  However, the LabVIEW Type ID "Enum U16" contains a space, but there is no possible ambiguity in replacing spaces with underscores here because we never need to "go backward" to get the "real" name of type Type ID.  The "human-readability" of these two formats are, to my eye, similar, and I would expect the parsing to be equally flexible.

 

It also should deal nicely with Constants.  There would be no trouble with a Tag -- it would just be the Type ID of the Constant.  Suppose the Constant had no Label or Name?  Oh, well, then it has no Name attribute!  So if you start matching on Tag and Attribute, it will (are you ready for this?) match a Constant that has no label, just what you might want.

 

Another idea that popped into my head (but don't yell at me -- I haven't really thought this out, and it might be a Really Bad Idea) would be to say that a "nameless" Tag can (possibly) match any Tag having a Name Attribute.  Like I say, I haven't thought this through, but this does raise some possibilities.  Maybe instead of having "no name" match anything, we could say that a Constant named "*" matches anything of the same Type (and, it turns out, you can drop a numeric constant and label it "*" with apparently No Ill Effects).

 

At the present time, I'm throwing these ideas out to the GXML Community for Comments.  One of the Really Nice Things about GXML is that it is LabVIEW Open Source, so we can see how it works and make it "work for us" (by, for example, accomodating our "# of Cycles" Variables).  It generates fairly straight-forward XML, so I anticipate it would not be difficult to write a "Converter" or "On-the-fly Translator" between the current GXML Format and the Inverted GXML Format I described here.

 

I will be attending NI Week in Austin in two weeks, and would be happy to discuss this with anyone who is interested in GXML (I'm hoping that Jeff Tipps, whom I think of as the Father of GXML, will be there to enlighten me).  I'll try to remember to check this Forum entry, but you can also send me a Private Message suggesting when/where/how to meet (perhaps with cell phone numbers).

 

Bob Schor

Message 125 of 132
(3,125 Views)

Hey Bob,

 

A very interesting idea.  I'm not sure I'm 100% sold on it, but definitely worth some thought.

 

Some background so you know where I'm coming from: I used XML extensively in a previous job for configuration files via a custom made C++ library and some perl scripts.  We used attributes extensively, including for "name".  When I started my current job which used LabVIEW, GXML was the best thing I could find at the time for handling config files (good balance of human readability and code performance).  At that point (around early 2012, if I remember correctly) we wrote the GXML interface to our main program, making it work with all the quirks and workarounds, and then pretty much forgot about it.  One of those aspects that we pretty much just accepted was the "no spaces in control labels" for our config clusters.  Now, looking at a random XML config file, I can't tell if "Part_Number" actually started as "Part Number" or not, but it ultimately is working for us.

 

So I'm all for using attributes, and I think the "name" attribute makes sense, but I have a mental block on using the data type as the Tag.  It could be just inertia, as I'm so used to reading and editing XML files as produced by GXML that I have a hard time changing my own mental parsing algorithm.

 

However, as I think further back to how I used XML before LabVIEW and GXML entered my life, I'm agreeing more with your idea.  Back in the day, we used the tag to identify how to parse the XML tag.  We knew what attributes and elements to expect based on the tag name.  Since we rolled our own parser, we weren't limited to "U32" or "Cluster", but instead had tags like "DAQ1544Config", which we knew would have attributes for "rate", "max", and "min", and elements for "DAQ1544Channel".

 

Coming back to the LabVIEW and GXML, my currently half-baked thought on this would be to not have the tag be something as specific as "U32", but something more generic like "Numeric", "Scalar", "Array", "Cluster", "String", or "Named Numeric".  So a tag of "Array" would always have attributes of "name", "type", and "dim", and would contain more tags as elements.  A tag of "Scalar" would have attributes of "name" and "type", and only contain a single value.  This is more done from an ease of parsing point of view, which doesn't really affect my code at all, since I just have the GXML parser turn it into a cluster for me.  But it might make the GXML parser more efficient if it had a standard set of tags and could figure out how to handle each item based on the tag.  I haven't dove into the GXML code in quite a while.

 

All this is purely a mental exercise right now, and I'm operating on limited sleep, so it might all be nonsense.

 

TL;DR: Use more generic "Scalar", "Array", "Cluster" as tag instead of "U32" or "String".

 

Mike

 

0 Kudos
Message 126 of 132
(3,113 Views)

Mike,

 

     Thank you for your comments.  My idea for the Tag was to not "re-invent the wheel", but to use the existing NI Type IDs that they automatically assign to all (I think) LabVIEW data.  You can see the list of possibilities by dropping down a GetTypeInfo function and looking at the Type Enum output -- there are currently 46 items, starting with "Invalid Type" and "Void", then the Integer types, the Floats, the Enums (including Enum U16), Floats with Units, Boolean, String, Path, Picture, Tag, Array, Cluster, Variant, and a dozen more.  Most are single-word types, but there are also 4-word ones ("Single Complex with Unit").

 

     My thought is that for most variables, a Tag made from the Type ID will be short, intuitive, and right next to the Name attribute (assuming we are dealing with a named Variable instead of a constant).  Incidentally, I just checked and a Constant returns the appropriate Type Enum and a Name consisting of an Empty String, pretty unambiguous.

 

     Just looking at the two "versions" of XML encoding that I presented, it occurs to me that it should be a relatively easy bit of coding to convert from "Name-centric Tagging" to "TypeID-centric Tagging".  What would be even nicer would be a small utility that could convert one format to the other, maybe even "auto-converting" if necessary.

 

     I'm hoping that in the next week or two other GXML Users will notice this and voice their opinions.  As I noted, I am planning to be at NI Week, so maybe if there are some other XML enthusiasts we could at least meet and argue discuss this ...

 

Bob Schor

0 Kudos
Message 127 of 132
(3,094 Views)

The timestamp issues that Biggeven reported on ‎06-26-2012 still remains. Will it ever be fixed?

Certified LabVIEW Architect
0 Kudos
Message 128 of 132
(3,007 Views)

Hi,

 

I am using the GXML package for some time now. The data to be stored keeps on growing, and the loading and saving time starts to get a real nuisance. At 1 MB XML file, it takes minutes. I know that XML storage causes overhead, but this is excessive. The profiler shows that most of the time is consumed in the GetTypeInfo.vi. This VI must retrieve the type of the variant such that the appropriate string for the type can be selected.It is called too frequently (as in call, forget the result, and call again), and it takes long, as in more time per call for all the frequently called functions.

I have pinpointed one case of calling too frequently and patched it to the snippet below. The trick is to forward the obtained information to the Unflatten and Scan.vi. It does have some effect, but at some 20% improvement, the effect is marginal. Higher efficiency of the GetTypeInfo.vi would do more. The implementation of GetTypeInfo.vi is hidden, so the question is: are improvements on GetTypeInfo.vi possible?

RecursiveFlatten.png

0 Kudos
Message 129 of 132
(2,813 Views)

Hi,

     I am looking for a way to create xml strings based on a custom schema. This schema consists of user specific datatypes. Actually I am new to xml and the related stuffs. But now I am forced to go through this as my project requires the inputs in form xml. I have attached a sample xml file and the schema file used to create the xml file. Could someone please help me to create similar one using labview. Thank You

 

 

 

Download All
0 Kudos
Message 130 of 132
(2,566 Views)