Write to file Question

[krwlz101]

I am doing some expirimental modeling with a VI that many members of this board greatly helped me get going.  Part of this modeling is the creation of an arbitrary periodic function.  I've accomplished this using 30 "Y-Value" Inputs, and a frequency to create sort of a "unit function", or basically, one period worth of the desired function, with a maximum amplitude of 1, so that it is easily scaled.

What I'm finding is that it would be nice to save these "Unit Functions" along with their corresponding amplitude and frequency to file, that I can later laod back into the program.  Thus, I need to both write the data to a file, (30 pairs of doubles, along with 2 independent doubles), and then have the ability to browse through all my saved functions, and load the desired one.

I've used the express vi "Write to Measurement File" before, but that seems like a clumsy method for this.  So I then played with the various "write to..." vi's available.

For a relatively small set like this, is there any benefit of one file type over another?  Obviously, much the data could go straight into an excel file, while it needs to be reformatted into strings to be stored in text.  I have little or no experience with bianary files.

Are any of the file types easier than others to then load from?

And is it possible to have the available (previously saved) functions selectable from a menu ring, or will I need to prompt the user?

That said, I'm just looking for some general pointers on the area.  I've read all the associated help files, and read quite a few threads on specific issue.  But being new, I'd like to hear how you professionals would approach this function.

Attached is my current code.

[Mark_Yedinak]

I would consider using a ini file format. Each of your saved data sets could be a section name. It is easy to read section names from the ini file so you could generate your ring control from that. The OpenG VIs have some nice ini processing VIs that allow you to read and write clusters very easily. If you create a cluster (typedefed of course) for your parametric data it would be very easy to use the OpenG Vis to read and write the ini file format.

[krwlz101]

Whoa, ok, never used OpenG vis before, and I am a bit overwhelmed at all the options!

Do you know what package those vi's are contained in?

EDIT:  Or should I just be downloading all of them?

Message Edited by krwlz101 on 03-24-2010 07:43 AM

[Mark_Yedinak]

I would download all of them. Grab the community version of JKI's Package Manager and install all of the OpenG packages. There are lots of useful VIs in there.

[krwlz101]

Got em all, looks like some very cool stuff in there.

That said, I should be looking to read/write ini section clusters of my data, correct?

Do I need to create an ini file first?  Would that be done with the "open config data" vi?

[krwlz101]

I'm also thinking I may need to create a state machine/queued state machine for this vi.  Currently, there is really only one set of operations, but I think the "load from file" and "write to file" options will really justify some more advanced architecture.

[smercurio_fc]

An alternative is to just use XML format. You can use the LabVIEW XML schema by using the Flatten to XML/Unflatten from XML functions. They're in the string palette.

[Mark_Yedinak]

Given your description of what you want to do I would define a typedefed cluster that contains all of your parametric data for your data sets. You might want to allow the user to name these data sets when they save them. You can use these names as the section name. If you pass in the cluster to the write VI with the section name the data will be saved. Using the section name you can later read the data back. You can use the built in config file VI to read the section names from the config file. This will allow you to initialize your ring control. One thing I generally do for my applications is allow the user to select the ini file that want to use. That way they can save multiple versions taliored to their particular task. You could do the same thing and therefore they could have multiple data sets tailored for particular uses. Just offering that as some added flexibility for your application.

Also, I generally don't include the handling of the config files in a state machine. This functionality is generally included in my UI task which is an event structure. Reading/writing/loading config files is more event driven by the UI than something in a processing state machine.

[Mark_Yedinak]

---

smercurio_fc wrote:
An alternative is to just use XML format. You can use the LabVIEW XML schema by using the Flatten to XML/Unflatten from XML functions. They're in the string palette.

---

While XML is convenient I find that if the configuration file needs to be modified externally by the user XML can be a pain to work with. It is easier if the editor supports XML and parses the data for you but it is a pain to work with in its raw form. Old style ini files in my opinion are easier to work with with a basic text editor.

[smercurio_fc]

---

Mark Yedinak wrote:

---

smercurio_fc wrote:
An alternative is to just use XML format. You can use the LabVIEW XML schema by using the Flatten to XML/Unflatten from XML functions. They're in the string palette.

---

While XML is convenient I find that if the configuration file needs to be modified externally by the user XML can be a pain to work with. It is easier if the editor supports XML and parses the data for you but it is a pain to work with in its raw form. Old style ini files in my opinion are easier to work with with a basic text editor.

---

I use Notepad++ with the XML editor plug-in. Makes working with XML much easier. 

I don't have anything against ini files - just offering an alternative.