11-03-2013 10:59 AM
Oops -- my just-previous post was a reply to Yee's 6-11-2010 post -- I didn't stop and think that it would look funny "detached" from the original question.
11-03-2013 11:17 AM
@LabBEAN wrote:
How would you read the data back as a known cluster if you are appending new data? Would the new trial-appended-data be in array form? Also, re: my post above: I like the idea of auto-handling all characters. Maybe merge our ideas and replace all forbidden characters with an underscore instead to prevent the the chance of collisions?
Sorry, LabBEAN, I overlooked your comment, but as you probably have seen, I basically agree with replacing "forbidden" characters with "something". I don't really have a problem with making all Forbidden into underscores -- in my code, I replaced spaces with underscores, forward slashes (used in dates, typically) with hyphens, and simply deleted the other characters (not a particularly good idea, since OK and OK? end up mapping to the same thing -- maybe use something like .<hex code>., e.g. .3F. for the question mark).
11-05-2013 09:59 AM
I've recently been struggling with a problem situation using the Search Parser. I'd earlier written that I'd made some modifications to the Parser that allowed it to handle a stream of identical XML entries (such as multiple clusters, written one after the other in a "concatenated" format) and return this as a LabVIEW Array. I'd written a little test routine that illustrated that this works, and went about developing some code to take advantage of this.
Well, so I now have an XML file that has a series of "Event Clusters" that I've written to it, but that GXML refuses to parse! I'm trying to figure out What Went Wrong (why does this cluster work, but that one fails?), and, in doing so, I'm diving (once again) into the depths of the GXML code (and am very grateful to be able to do so!).
Here's an observation, and a question. The Observation is that GXML (and, I believe, XML in general) is written as lines of text, with each line typically holding one XML "feature". The internal LabVIEW representation of this data is a (single) String, and when assembling and disassembling this String, care must be taken of the String Terminators (<CR><LF>). What, if anything, would be the drawback to changing the internal representation to an Array of Strings (still reading and writing the text file as a "flat string" with the appropriate EOL characters). This would certainly simplify the parsing logic, since you would (naturally) be working on a line-at-a-time level, which corresponds, in a natural way, to an element in a String Array.
I do realize that Jeff may not have the time/energy to devote to this, and there may also be Important and Deep Reasons that I haven't considered. I'm still pretty involved with the project that led me to start using GXML, but I'm "nearer than farther" (as my wife's grandmother used to say), so if Jeff gives an OK, I'm willing to explore making this change. If I do, I will also produce (more) documentation, and describe (more) fully some of the other changes I've incorporated in my copy of GXML that seems to enhance its flexibility and utility. I would imagine I could have this done by the end of the calendar year.
Jeff, please give me some guidance -- is this a Good Idea or a Fool's Errand?
BS
11-05-2013 12:25 PM
Hello Bob,
You really taking me down memory lane with this question. I don't know if you have seen this or not but the "Quick Parser"s first operation is to convert the XML string to an array using the carriage returns and line feeds as delimiters. This does in fact make the parsing simpler for that function. I remember considering this approach in the search parser as well. I had two concerns at the time that I admit I didn't fully investigate but were both solved by keeping the GXML string as one giant string.
First I question how this approach would impact searching efficiency. The parser VI (GXML.lvlib:Get Tag Contents.vi) would get the extracted array of strings (each element being a line) and the tag to search for. To search for the lines that contain the opening and closing tag of that name would mean the function would have to iterate through the array and perform a match expression on each line. By keeping it as one giant string I only need to call that function once for the opening tag and once for the closing tag.
Secondly I am concerned about how LabVIEW was going to pass all of this data recursively to the stack. Ideally this would be done with pointers but if LabVIEW was going to copy the entire sub-structure for each recursive call, I was afraid that copying an array of smaller strings would require more memory and more dereferencing of pointers than copying one giant string.
Currently the main weakness of GXML is the execution time of the Search Parser when having to parse structures with multiple levels of heirarchy on Compact RIO. It is a little faster than implementations that use VI Server recursion but many times slower than LabVIEW's unflatten primitive. I would be hesitant to make changes that affected execution time in a negative way.
Thoughts?
Jeff Tipps - S&V Systems Engineer
11-05-2013 12:34 PM
Funny you should mention that, but I have printouts on my desk (made yesterday afternoon) of the Quick Parser, the Search Parser, and its "main Squeeze", the Recursive Parse. I do see your point about "recursive overhead" -- let me think a bit about it and see if I can't come up with a Recursive Solution. [I wonder if this is a good place to use Data Value References, which I've heard about at NI Week, but never have tried nor completely understood ...].
I hope to have some insights within a week. I'm encouraged by your comments!
BS
11-10-2013 12:04 PM
As we used to say in my Freshman Physics Course, "Answer Analysis reveals that the Question is Wrong!". I was struggling a few posts ago with the question "Why can't I read (using the Search Parser) GXML Data that I just wrote?".
I'd written a Demo routine that created dummy data based on a Cluster TypeDef, created multiple GXML strings (representing individual "readings") and wrote them to a single GXML file (a "concatenation"), then read them back one Cluster at a time with my modified Search Parser, building (at Read Time) an Array of Clusters for me. Yet when I tried to read back data from a GXML file I'd generated as part of a Data Acquisition program, it returned nothing!
The "secret" (or "bug", or "feature") is that when you write a LabVIEW Variable (in my case, a Cluster) to a GXML file, you must read it back into a Variable that not only has the same Type, but the same Name. As it happened, I was writing the output of a VI whose output terminal was called "Event Out", and when I wanted to read the XML back in, I passed in the Typedef for the Cluster that "named" the Cluster "Event". So the Search Parser failed to find it!
Whew! This means I'm going to put off trying to rewrite the Recursive Parser, and am also going to put off experimenting with replacing the gigantic GXML string with an Array of Strings. It's the "If It Ain't Broke, Don't Fix It!" syndrome. But I will try to do a full write-up on GXML, with my "extensions", before the end of the year ...
01-21-2014 04:35 AM
Hi, I would like to know which xml element attributes are really considered by the GXML parser in total?
I only know about type= and dim=[] , are there any more? And which functionality is linked to?
regards
Edmund
03-24-2014 10:02 AM
Hello,
Allow me to briefly describe my project. I am acquiring 128 samples from an Analog Signal Generator connected to an NI 9215 module which is placed on a cRIO 9073 chassis. After passing the samples from the FPGA to the Real Time environment (FIFO) they are Base64 encoded so that are converted from binary to ASCII.
The Base64 represantation of the samples should be put in a payload of an XML frame. Thus I am trying to generate the XML format I have attached bellow. I have tried both GXML (GXML concatenation example) and Simple XML (Unflatten to XML) but I can not reach the desirable format that is crucial for my project. I would much appreciate any suggestions you can provide me with.
Anastasis
11-04-2014 10:01 AM
Hi,
I have encoutered a problem in the GXML library, when trying to read a 'double' value in a CompactRIO (eg. 0.008) it would return a integer number (eg. 0).
I've tried to read the same xml in a computer using the same blocks and it has returned the correct 'double' number.
Has this happened to anyone?
Ps: The computer in wich i'm programming uses a coma as a decimal separator, so the number i'm trying to read from the xml is 0,008, for example. I don't know if this makes any difference.
03-25-2015 07:03 PM
All,
I hope this is the correct area to post this question. The problem i'm trying to solves is how to search and XML string for a particular tag, edit the tag and the write new XML string to file. I'm using the XML file as a configuration file and need to updated tag parameters.
I am using reference example & GXML and LV XML palletes, i was able to do this (see attached code below) on the windows PC, however i need the code to run on a cRIO-9022, and some of the LV XML .vi's are not supported for RT platform.
What options do i have, i have tried using the GXML search parse function for a particular tag, but have had no success.
Any pointers or comments would be appreactied.
Tim