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

[mq17]

Hi Jeff,

thank you for this nice piece of software.

I had to make a minor modification in gxml_NameFilter because (living in Germany) not all of my variable names are composed of ASCII-characters only. So I changed the [^a-zA-Z0-9.-_] expression to [\W] and the starting character expression to [0-9.-_]. Seems to work so far. BTW gxml_Generator.vi misguides you with its error message, identifying itself as gxml_Builder.vi.

I've also ported GXML to LV 8.6 using the techniques shown in http://digital.ni.com/public.nsf/allkb/7140920082C3AC15862572840015A81E.

So far, I'm quite happy with the tool.

Regards

Matthias Quade

[Jeff_T.]

Matthias,

I am glad you are enjoying the content and that you can modify it to your needs.

I also recently noticed the error description discrepency and fixed it.  Are you using the latest installer (version 1.4)?  You can look it up in the control panel/program list.

The link you provided is broken.  What technique did you use to back port it to LV 8.6?  I thought native LV recursion only worked in LV 2009.

Regards,

Jeff Tipps

S&V Systems Engineer 

[Miha_Vitorovic]

---

@mq17 wrote:

I had to make a minor modification in gxml_NameFilter because (living in Germany) not all of my variable names are composed of ASCII-characters only. So I changed the [^a-zA-Z0-9.-_] expression to [\W] and the starting character expression to [0-9.-_]. Seems to work so far.

---

Hi Jeff,

have the changes suggested by Matthias been already incorporated into the library, or do we have to patch it ourselves?

Br, Miha

[mq17]

Jeff,

I was using version 1.4.

The link has grabbed the sentence closing dot, so just trim it. In LV 8.6 you have to use VI server calls.

http://digital.ni.com/public.nsf/allkb/7140920082C3AC15862572840015A81E

I have to correct my former post since '\W' does not work as expected, at least not in LV. So in order to use the Latin-1 character set (ISO-8859-1) in XML tags you have to include every literal (e.g. äöüß) in the regular expression. To look at such a XML file outside of GXML the prolog ('<?xml') has to announce the encoding (encoding="ISO-8859-1").

Of course the easiest way is to avoid international characters in your LV labels.

The method above can help you only with literals. Special characters (e.g. [°]) can be part of LV labels but are not XML compliant. They must be avoided (put them in the captions). gxml_NameFilter could replace them with '_' like the space character, but this could lead to duplicate or unreadable tags.

Regards

Matthias

[mq17]

Jeff,

while further testing GXML I ran into a problem with the timestamp. You use %x for formatting and scanning the date. %x depends on the settings of the operating system. What is 08.07.2010 in German Windows becomes 07/08/2010 in US format. If there were only the timestamps to write and read this would not be a big problem as long as you don't try to read the XML file in an operating system with another formatting. But during parsing you use gxml_TimeCheck which expects the '/' in the date format. I think a better solution would be a format like %Y-%m-%d for the date.

BTW I found another misleading error message. gxml_QuickParse identifies itself as gxml_BlindParse.

Regards

Matthias

[mq17]

Hi,

another problem with GXML and localization is the decimal point. GXML uses '%g' to format and scan floats and doubles. This uses the decimal point setting of the OS, i.e. a ',' in German Windows and a '.' in US-Windows and (important for me) in LabVIEW-RT (Pharlap ETS), where I cannot change it. So to make my GXML files portable I changed all the occurrences of '%g' to '%.;%g' forcing GXML to use the dot as decimal point. In this way the GXML files are independent of the OS settings.

Regards

Matthias

[Jeff_T.]

Awesome Matthias thank you for the great suggestions.

Regards,

Jeff Tipps

S&V Systems Engineer

[Miha_Vitorovic]

Is there an XML schema defined for the XML? Or do we have to create it "from the code"?

Thanks in advance, Miha

[mjaspan]

Jeff -

  this library is fantastic.  It accomplishes for me what I have struggled to figure out how to build myself.

  I'm hoping you can help me solve a mystery.  I'm having some mysterious trouble using GXML with the Build to WebService.  The symptom is that when I include one of your VIs in any of my VIs, the build and deploy process completes without errors, however the webservice simply does not deply.  HTTP requests are answered with 404 errors and the Distributed System Manager does not show the webservice at all.

  In troubleshooting this behavior I identified some VIs in your library which seem to have a mysterious property that causes this webservice-failure-to-deploy behavior.

  As an example, the VI "gxml_GetArrayDim.vi" has this property.  I manually duplicated this VI as best I could - functionally my VI works the same, however my VI does not trigger the webservice-failure-to-deploy behavior.

I've attached a simple project with two VIs which illustrate the issue. One works, one doesn't.  They are as identical as I can figure out how to make them.

http://localhost/query1/querydemo1 - responds correctly

http://localhost/query2/querydemo2 - responds with 404 error.

Any thoughts you have on diagnosing this issue appreciated,

 thanks,

  Martin Jaspan

  Lumarray, Inc.

[mjaspan]

Jeff,

  I've resolved my issue.  It turns out there's a minor incompatability between your library, WinXP, and LabVIEW 2009 Web Services.  It stems from file path lengths.

  The problem is particularly insidious because Web Services produces no errors in this case, but will simply fail to work.  The Web Service will claim it deployed successfully, however it won't respond to HTTP requests AND it will not be listed by the Tools/Distributed Systems Manager. 

  Special thanks to NI tech support for helping me track down that I was suffering from a limitation for LabVIEW 2009 with WinXP.

  I'm posting the details here in case anyone else stumbles on this issue.  There's 3 parts to this problem.

Fact 1.  The default installation directory structure of your GXML library results in file path lengths up to 136 characters. 

(For Example, "C:\Program Files\National Instruments\LabVIEW 2009\user.lib\GXML\_subVIis\GXML SearchParser\Parse Array Info\gxml_GetArrayElementInfo.vi")

Fact 2.  Under Windows XP, LabVIEW 2009 can only handle file path lengths can only be up to 255 characters.

Fact 3.  When compiling a VI for Web Service, the path length of the Deployed Web Service has approximately an extra 160 characters added to the path length of each VI, which adds up to more than 255. 

(For Example, " C:\Documents and Settings\All Users\Application Data\National Instruments\Web Services 2009 32-bit\UserServices\deployed\service-4F407021-93B9-4F3B-8086-E04A4FFBA3AD\internal.llb\LabVIEW 2009\vi.lib\DAQmx\create\channels.llb\DAQmx Create AI Channel (sub).vi")

The upshot of all of this is that if one wishes to use your GXML library in VIs being built and deployed into Web Services, they need to rearrange the file locations to have shorter paths, or use Windows 7, or upgrade to LabVIEW 2010.

Apparently the 255 character file path issue is no longer a problem with Window 7 or with LabVIEW 2010. 

Thanks again for a great library,

  Martin