06-13-2011 10:37 PM
Has anyone noticed that GXML incorrectly populates clusters when parsing clusters with the same number of members?
I have the following xml file:
<?xml version='1.0' standalone='yes' ?> <ATE> <TestEquipmentID mems='6'> <ATESerialNumber type='String'>12345</ATESerialNumber> <ATEPartNumber type='String'>C31-C20-123</ATEPartNumber> <ATELocation type='String'>here</ATELocation> <ATESoftwareDocument type='String'>C31-C20-009 REV 1.0</ATESoftwareDocument> <ATECalibrationStatus type='String'>PASS</ATECalibrationStatus> <ATECalibrationDate type='String'>2011-06-23T15:50:33</ATECalibrationD
ate> </TestEquipmentID> <TestInformation mems='6'> <EquipmentType type='String'>Equipment</EquipmentType> <OperatorName type='String'>OperatorID</OperatorName> <DateTime type='String'>2011-06-23T15:50:33</DateTime> <Duration type='String'>25</Duration> <TestType type='String'>OEM Productions Sell-off</TestType> <Comments type='String'>Comment</Comments> </TestInformation> </ATE>
I also have control cluster containing these two clusters called Debug Test Data.
I have a VI where the XML file is parsed. When the VI is run, the TestEquipmentID and TestInformation display boxes on the Front Panel are both populated with the TestEquipmentID data, even though they contain different fields with different values.
When I edit the cluster and the xml file so that the clusters have a different number of members (I one has 5 and the other has 6 members), and run it again, the data is parsed correctly.
Any ideas what could be going on here?
06-13-2011 11:31 PM
I've done some more debugging, and discovered that the problem was outside of GXML. The TypeDesc input to the GXML Search Parser was being populated with fields from the wrong cluster.
I've managed to fix it by adding a "To Variant Function" to the link from the TestInformation unbundled item to the input of the Search Parser.
Hope that helps anyone who comes across a similar issue.
06-15-2011 10:46 AM
Whoa this is bizarre. Yeah I can reproduce this behavior reliably on my end and the red dot / explicit conversion makes all the difference. In fact sometimes the first VI takes on the values of the second. Weird.
Thank you for reporting this. I have filed a bug report to our LabVIEW R&D team.
S&V Systems Engineer
07-17-2011 04:11 AM
I really have a big problem using gxml_Generator in cRIO webservice. The webservice is just returning plain values, not xml formatted.
I'm using Windows7 with Labview2010. If I run the code in development environment, is returning the correct xml formatted string. After I'm building the webservice, is returning unformatted string.
07-20-2011 11:39 AM
I don't have a lot of experience with LabVIEW webservices [yet]. Can you reproduce the behavior with any XML string? If so I recommend you visit the general LabVIEW support forum and talk about the webservice there.
10-28-2011 09:07 AM
Found some rather interesting bugs in this library. Overall I have to say I am very impressed, definitely the best way to work with XML in LabVIEW that I have found.
I am trying to store an enum that has different comparison operators as it's strings: "=", "<", ">=", etc. Unlike when I write a string to XML, the special characters do not get changed to "<" or ">", they just show up as "sel='<'" in the attributes of the item.
Some effects of this:
When I store an enum with a "<" selected, it causes some XML viewers (like Internet Explorer) to flag an error.
When I store an enum with a ">" selected, the quick parser vi responds with error 537530 "gxml_BlindParser.vi <ERR>XML item 'Operator' has data that is not valid and could not be parsed." However the search parser works fine.
The workaround for my specific problem is to use "LT" and "GT" instead of "<" and ">", but I thought I would let you know about this.
Also, I am unable to find any use/licensing information. The library is listed as a "Customer Submitted Example", but then states that it was developed by an NI group. Are there any use restrictions on this code?
11-04-2011 04:26 PM
Hello Mike sorry about the delay in getting back to you.
Yup that is indeed a bug. I will look into using the special characters in the tag attribute. I don't recall if that is allowed or not, if not then I will throw an error saying those characters are invalid (that is probably what it is going to come down to).
As far as reuse, you may build GXML into any number of applications and distribute those applications as many times as you want. There are some limitations (like copywriting the SW as your own) but we are still developing the official "Terms and Conditions". What is it you would like to do?
02-07-2012 10:39 AM
Would it be possible to get an xsd for GXML?
Does that question even make sense? (The vagaries of XML are new to me and I don't know if an xsd would be specific to a particular cluster, or if a general xsd would apply to GXML.)
If an xsd would be specific to a cluster, would it be possible to generate xsd from a typedef?
05-22-2012 11:09 AM - edited 05-22-2012 11:11 AM
On a recent project, I used GXML to save an array of a type def cluster where one of the type def parameters was important for me to quickly identify. I decided to store that parameter as the Version Tag Name/String and used the gxml_ConcatGXMLStrings utility VI to generate the single XML string that was saved. However, I wanted to be able to "un-concatenate" (is that even a word?) the string once it was read so I could use the gxml_GetTypeDefVersion utility VI for each element of my original array. I have attached the VI I created to do this as well as an example - I simply modified the included GXML Concatenate example. Hopefully this will be of use to someone else.
Note: gxml_UnConcatGXMLString.vi uses the String to 1D Array OpenG VI