LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reading/Writing Config text data file of different sizes

Hi all,

 

So I've built a VI to read config files which are basically flattened text files and subsequently am able to overwrite them should I choose to.

 

It has worked as intended thus far but now I want to be able to read config files of different sizes and when overwriting I would want to be able to change its size again (ie adding or subtracting more parameter text/numeric fields) when I press save.

 

However due to the constant wired into the type of the Unflatten from String step when reading the config file, that is not possible. How do I make it a "dynamically changing"(I'm not sure if that's the right term) array and not one of a fixed size?

 

Does anyone have any idea how to make it work?

 

Thanks in advance!

0 Kudos
Message 1 of 29
(3,306 Views)

Use the Config File Read/Write VI's in a subpalette of the files palette!.

 

You break your data into smaller chunks.  You have key and value for each item of interest.  Of course you'll still have to do some programming to go through this list of keys to get the values and decide what you are doing with them.  You can't honestly expect to randomly add and subtract items from a file and expect LabVIEW to miraculously know how to handle the items you are adding.

 

But one toolkit I use that you can find on the VI Package Manager from JKI is called MGI Read/Write Anything from Moore Good Ideas.    It just seems to do a better job handling clusters of data.

0 Kudos
Message 2 of 29
(3,296 Views)

The reason why the config file was written as a binary text file and not the using keys because there's quite a lot of parameters to set (like there's a tab control and each tab contain anywhere from a cluster of 4 to 45 items but I want to be able to "add" more items as parameters if I click on a button). One workaround is to use a constant with a very large set size and leave some fields blank when necessary. However, I feel it's more intuitive to only add parameter fields when needed (as it could vary from one test object to another).

 

I did try installing the toolkit you suggested but unfortunately I keep getting the message that it's not compatible with my system and/or LV version for some reason...

0 Kudos
Message 3 of 29
(3,274 Views)

I'll second the motion for the MGI Read/Write Anything package -- I've been using it through small version changes for probably 15 years.

 

Dunno what your install problem is unless maybe you're running LV 2020?  I downloaded LV 2020 Community Edition as soon as I knew it was available, only to find that I couldn't yet easily install VIPM packages for it because VIPM was not yet aware of LV 2020.  (Maybe that's changed now?  I haven't gone back to check.)

 

One really nice thing about the MGI package is that the INI file isn't *required* to define values for every field in the cluster.   Read Anything will use the ones it finds and the others will retain default values. 

   This *can* be the datatype's default, i.e. 0 for numerics, False for booleans, empty for strings and arrays, etc.   But it's usually more useful to feed it a cluster of desired default values and then also feed it a True to tell it to use those values as defaults if overrides aren't found in the INI.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 29
(3,241 Views)

Just  to throw out another option, there is also JSONtext from JDP Science available through VIPM.  It has 2 functions (To JSON Text and From JSON Text) that will convert your cluster to and from a JSON string.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 5 of 29
(3,235 Views)

I don't know the JSON tool crossrulz mentioned, but I would trust his opinion.  While I can typically stick with simple INI files for my configs, formats like JSON and XML are more natural at supporting hierarchical data structures.  I've done a little work with XML, pretty much none with JSON.  My limited experience with XML sent me back to simpler INI files as my personal standard, but that was years ago without any of the available packages or toolkits.

 

Of the 3 formats, JSON probably has the best legs for the longer-term future.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 29
(3,201 Views)

I have just started A new project. I have used the OpenG Variant Config files for years but this time I have opted for JDP Science Json text. I am very happy with it so far. Json is great and easy to share cross platform and when I need to track changes it will be seamless to move to a database by using JSON. 

Message 7 of 29
(3,194 Views)

I managed to download the MGI Read/Write Anything package now. 

 

So if my parameters have a cluster of a variable amount sizr of numeric, text and booleans, should I just wire a cluster with like one of each type to the "Type of Anything" then? Then regardless of size it should read/write the config file? Have I understood it correctly? Or do I just wire a variant constant?

 

And what exactly is Section Name and how is it wired? (For example, I have a tab control for user organization and each tab contain a cluster of different parameters to set...is the section name the label of the tab then? Also, I guess I run into the next problem of changing the number of elements in the cluster programmatically because that's where I want to add more 'parameter' fields....)

 

Sorry for the dumb questions, because I've only dealt with extremely simple and small config files before this. Thank you again.

0 Kudos
Message 8 of 29
(3,162 Views)

@Kevin_Price wrote:

While I can typically stick with simple INI files for my configs, formats like JSON and XML are more natural at supporting hierarchical data structures.  I've done a little work with XML, pretty much none with JSON.  My limited experience with XML sent me back to simpler INI files as my personal standard, but that was years ago without any of the available packages or toolkits.


I'm having the opposite problem.  I am finding my hardware configurations more complex than can be easily understood in ini files.  I need the hierarchy.  So I started using XML.  My last project I gave JSON a try and the JSONtext library saved me soooooooooooooooooo much time just using the two functions I mentioned previously.  And most software developers know JSON already, so it was fairly simple to tell them how to make edits to the configuration.  My only real issue with JSON at the moment is the lack of a good edit tool.  XML has XML Notepad, which is really nice since you edit the file in a tree structure.  I have not found something similar for JSON, though I haven't really looked either.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 9 of 29
(3,150 Views)

1. Make sure you make a typedef out of any cluster you define!

2. Go back and be sure you followed step 1.

3. What you wire to "Type of Anything" should be your (typedef'ed) cluster, not a variant constant.

4. "Section Name" is either whatever string you wire in or, if you leave it unwired, the default behavior is to auto-name based on the label of the cluster you wire in to define the type.

    I used to use the auto-naming behavior but have switched to explicit naming.

 

5. Some of what you describe sounds like you'll need another level of programming work.  A cluster binds together a specific set of types in a specific order.  Visual representation of a cluster will include a border around all the items, though it's possible to move items around *geographically* without changing the previously mentioned order.

    This often won't be the nicest way to lay out your user interface though.  So you may find yourself using "Bundle by Name" to bring the values from the individual controls on the GUI into a cluster you can feed to "MGI Write Anything".  And vice versa when you read.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 10 of 29
(3,125 Views)