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
"unflatten from XML" with default values
eultof
Member
11-14-2006 11:02 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
I want to make a type dependent parameter file to allow a program to work with different parameter set. I found a nice solution by using XML files.
All parameters (numbers, text, clusters..) of a set are all in a cluster. Then for a file including 5 types, I have an array of 5 clusters. I enter this array in the "Flatten to XML" VI and I get an XML file. In the other way I use the "unflatten from XML" VI and it works.
But my software will change in the future, and surely have more parameter per type. The ideal situation would be to work with a new cluster size and in the case of an old parameter XML file, the missing datas are replace by a defined default value. But it doesn't work like that with "unflatten from XML" : it simply set an error and put the default value for each type of data (0, "",...), that is for me not so interesting...
Any idea?
HJPhilippi
Member
11-23-2006 06:55 AM - edited 11-23-2006 06:55 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
In fact, it's not too difficult to achieve what you want if you design the data/XML layout well. First of all, I would generally split any data in a "Header" and a "Content" section (name it what you like). There's a reason why all text protocolls like HTML or SOAP make it like this, too.
😉
Within the Header section (an array of possible "DataInfo" types), you should store information about the file itself = data structure or VI version info (very important!), how the reading VI should treat missing data and so on. The "Content" section then gets the actual values, once again an array of recurring "DataContent" types. If the "DataContent" types are e.g. pairs of data and metadata (type information strings), they will deal with literally any data you want to store now and in the future.
It's the job of your forthcoming VIs to know what to do when an old data file is read - at least, they'll have the version info of the file and get aware of some old stuff coming up... with handing out predefined standard values for data missing in the old file!
It's pretty easy to write some wrappers around the simple flatten/unflatten XML functions of LabVIEW to get the described comfort.
Greetings,
Hans
😉
Within the Header section (an array of possible "DataInfo" types), you should store information about the file itself = data structure or VI version info (very important!), how the reading VI should treat missing data and so on. The "Content" section then gets the actual values, once again an array of recurring "DataContent" types. If the "DataContent" types are e.g. pairs of data and metadata (type information strings), they will deal with literally any data you want to store now and in the future.
It's the job of your forthcoming VIs to know what to do when an old data file is read - at least, they'll have the version info of the file and get aware of some old stuff coming up... with handing out predefined standard values for data missing in the old file!
It's pretty easy to write some wrappers around the simple flatten/unflatten XML functions of LabVIEW to get the described comfort.
Greetings,
Hans
Message Edited by HJPhilippi on 11-23-2006 02:01 PM
