From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
LabVIEW XML, GXML, or EasyXML?
Solved!
Bob_Schor
Knight of NI
08-30-2013 04:52 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
I'm developing some routines to collect behavioral data. I want to generate a "Header file" that contains two kinds of data -- Experiment-wide (constant) data, such as the name of the subject, the settings of the equipment, date, etc., and "trial-by-trial" data, such as what stimulus was used and what response was recorded. I will also be collecting analog and digital data in separate files, and will record "pointers" into those files as part of the "Trials" data.
It occurred to me to use XML to write the Header File. My thoughts are that being "human-readable" was a plus, and the file format would "naturally" be driven by the data that is generated.
I notice that there are three sets of XML routines, the "native" LabVIEW XML VIs, an NI "package" called GXML, and a set of routines from JKI called EasyXML. Other than assuming that EasyXML is "easy-to-use", are there any recommendations or suggestions as to which to use? Do they have different functional properties? What are the reasons to prefer one over the other?
Solved! Go to Solution.
mikeporter
Proven Zealot
08-30-2013 09:55 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Of the options you gave, I would choose JSON strings...
It's still human readable, a lot smaller than XML and is trivial to convert front and into native LV data structures -- at least in LV 2013.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
For help with grief and grieving.
08-31-2013 12:25 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
@mikeporter wrote:
Of the options you gave, I would choose JSON strings...
What is a JSON string? How do I learn more about this option?
BS
mikeporter
Proven Zealot
08-31-2013 12:58 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Google "JSON".
The name stands for JavaScript Object Notation and it is a standard. LV2013 has built-in functions for converting native LV data structure into JSON and converting JSON back into native LV data structures.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
For help with grief and grieving.
Solution
Accepted by topic author Bob_Schor
09-03-2013 03:34 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
After doing some tests, the Winner appears to be .... (drum roll, please) .... GXML. It produces "clean-looking" output, is fairly easy to use, and has "modifiable" features (I've made a few "minor improvements" that make it more forgiving of the data I'm throwing at it). Here's hoping that it continues getting support from the Community and from NI, and maybe becomes better known and more easily available.
DAckermann
Member
01-14-2014 04:42 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
I would like to point to another alternative. We created a library that is similar to GXML but is based on cluster references. It offers more flexibility and can easily be used with LabVIEW classes.
Cheers
