Best practice concerning .ini file read out

[PascalOehler]

Hello LabViewers

I have a rather large application which is using a lot of hardware communication to various devices. I created an executable because the software is running at multiple locations. Some settings are currently hardcoded, others I put into a .ini file, such as the camera focus. The thought process was that these kind of settings might vary from location to location and can be set by a trained user into the .ini file. 

I would now like to expand the application by being able to use two different versions of the key hardware device (an Atomic Force Microscope). I think it makes sense to do this by using two versions of .ini file. I am intending to create two different .ini files and a trained user could then again adjust settings, such as the camera focus, if needed. The other settings he can leave untouched. I also inted to force the user to select a .ini file when the executable starts using a file search dialog, unlike now where the (only) ini file is automatically read in. If no .ini file is specified the applicaiton woudl then stop. Does this use of .ini file make sense?

My actual question resolves now about how to handle the read-in of the .ini file. My estimate is that between 20-30 parameters will be saved in the .ini file I see two possibilities but I am not sure what is the better choice or if im lacking a third one

1) (current solution) I have created a read-in vi where i write all values of the .ini to global variables of the project. All other VI's only read out the value of the global variables (no other write) to ommit race conditions

2) I pass the path of the .ini file into all subVIs and read out the values of the .ini file where needed. I can open them as read-only. 

What is best practice? What is more scalable? Pros/Cons? 

Thank you very much 

[crossrulz · Accepted solution]

1. I recommend just using the one configuration file.  You just have a key to say which type of device is actually being used.  This will make things simpler on the user since they won't have to keep selecting the right file.

2. I use the globals.  There is no need to constantly open, get values, and close a file when it will be the same everywhere.  And since this is just a one time read at the start, globals are perfect for this.

[PascalOehler]

Concerning point  1, this would then mean that the user has to specify at one point what device he is going to use given that the device cannot communicate this information itself?

[crossrulz]

---

@PascalOehler wrote:

Concerning point  1, this would then mean that the user has to specify at one point what device he is going to use given that the device cannot communicate this information itself?

---

Correct.  It is just a matter of where they specify the device: one time in the configuration file or every time they open the application.

[ben64]

---

@PascalOehler wrote:

I have a rather large application which is using a lot of hardware communication to various devices. I created an executable because the software is running at multiple locations. Some settings are currently hardcoded, others I put into a .ini file, such as the camera focus. The thought process was that these kind of settings might vary from location to location and can be set by a trained user into the .ini file. 

I would now like to expand the application by being able to use two different versions of the key hardware device (an Atomic Force Microscope). I think it makes sense to do this by using two versions of .ini file. I am intending to create two different .ini files and a trained user could then again adjust settings, such as the camera focus, if needed. The other settings he can leave untouched. I also inted to force the user to select a .ini file when the executable starts using a file search dialog, unlike now where the (only) ini file is automatically read in. If no .ini file is specified the applicaiton woudl then stop. Does this use of .ini file make sense?

What is best practice? What is more scalable? Pros/Cons? 

Thank you very much 

---

I usually try to avoid multiple ini files but there are cases where it make sense to have more than one. I have a test software that is used to test different but very similar units (same tests are performed but with different supply voltage and with different pass/fail criteria). In this case I have type A and type B  ini file that are selected based on the unit assembly number.

I also avoid harcoding any setting as much as possible.

Ben64

[RTSLVU]

Consider using XML instead of a text based INI file.

Using the XML vi's you can basically search the XML file for the tags as you need them. 

[JÞB]

There is one phrase that makes me scared.

You said "Trained User"... So, I will ask you, how well documented your code is?  Yes, I when right there! Unless you document the ini options very well, you should not let users near the configuration file!  That is just asking for tons of follow on support.  (Of Course, if you have negotiated a way to get PAID for that support you might be a bit ahead of the curve)

Trained Users... Very uncommon! "Push the button get a banana!" that is what you should try to achieve with your product.

[mikeporter]

My recommendation is not to use an INI file at all. Use a database. In the long term it's easier and will produce far fewer headaches -- even in the short term.

Mike...

[PascalOehler]

Hello Mike

Could you elaborate on this? I guess this would become interesting if I have, say, 5 or more deployed systems?

[Sam_Sharp]

- INI files are fine, I use the following snippet for loading/initialising a configuration file and it has worked very well for me over the years and lots of changes I've made to software that uses it:

It uses the OpenG Variant Configuration File VIs.

XML is OK but don't use the LabVIEW XML primitives as they will fail on reading the file if the structure changes - you'd need to read/write the individual elements.

For databases - you could either have a local SQLite database stored with your application which stores key/value pairs - you could even include configuration history by timestamping the records/keys and only selecting the latest value for each one. The other option is a networked database (e.g. MySQL / MS-SQL etc.) - similar schema, but it means your configuration data is centralised. You'd need to consider what to do if you can't connect to the database.