Configure ini file simplicity in 7.0?

[JPrevost]

So here I am working with a large program that has user configurables and I want an easy way to save them and recall them. I have the read from cfg done before any of the loops start to run and I use locals to write to the controls (is there a better way?). Then, on my program's "stop" button value change event I have a sequence that writes the new values from the locals to the cfg. All is fine and dandy except that it's taking up a lot of real estate. This program is rather large (an all-in-one tuner/datalogger for automotive EFI) and I don't have that nifty feature from 7.1 called navigator . I just started my own buisness with a friend so we can't afford the upgrade just yet. If there is an easier way to save cfg data and recall it I'm all ears.

[Jim Kring]

You should check out the Variant Configuration File I/O VIs from OpenG. These can read and write anything to an INI file (clusters, arrays, etc.). Download OpenG Commander and make sure that the variantconfig package is installed.

[JPrevost]

You should check out the Variant Configuration File I/O VIs from OpenG. These can read and write anything to an INI file (clusters, arrays, etc.). Download OpenG Commander and make sure that the variantconfig package is installed.

I've been reading about OpenG this and OpenG that but I don't know where to start. There is very limited documentation explaining why anybody would want whatever it is OpenG offers . Maybe I suck at researching but I'm pretty sure I'm not.

Breifly, what is the advantage of OpenG other than it being "free"? Do I need to install Commander before I can use/install the OpenG Toolkit/Builder? Is there a chance that installing this software will break my current LabView program causing a reinstall? Will I need to package new run-time lib for sending out to beta testers that have only installed the main run-time? Currently I enjoy sending out updates of just a compiled exe to replace the old... I'm sorry for all of the questions but the OpenG websites I've visited haven't given me my answers. Would be nice to see some screenshots . Last question, if you don't mind; Is the OpenG builder a replacement for the LabView application builder or is it just a builder for wrapping vi's to send as toolkits?

The more I know, the more help I can be in the future. I plan to stick with LabView for life... eventually helping out with this OpenG stuff

[Neville D]

I've been reading about OpenG this and OpenG that but I don't know where to start. There is very limited documentation explaining why anybody would want whatever it is OpenG offers . Maybe I suck at researching but I'm pretty sure I'm not.

Breifly, what is the advantage of OpenG other than it being "free"? Do I need to install Commander before I can use/install the OpenG Toolkit/Builder? Is there a chance that installing this software will break my current LabView program causing a reinstall? Will I need to package new run-time lib for sending out to beta testers that have only installed the main run-time? Currently I enjoy sending out updates of just a compiled exe to replace the old... I'm sorry for all of the questions but the OpenG websites I've visited haven't given me my answers. Would be nice to see some screenshots . Last question, if you don't mind; Is the OpenG builder a replacement for the LabView application builder or is it just a builder for wrapping vi's to send as toolkits?

The more I know, the more help I can be in the future. I plan to stick with LabView for life... eventually helping out with this OpenG stuff

Lots of free, useful tools for array/number/boolean/file/string manipulation etc etc.

Yes you need to download and install the OpenG commander, and then from Tools menu start the commander and download and install all the separate packages. This is so that each package can be updated independant of all the other OG packages.

Installing it will do nothing to your original LV install. It just places a bunch of useful VI's in your user.lib folder, and various other stuff in your other LV folders (all of it pretty harmless). As far as I know, it does not make any entries into your registry (it is after all platform independant).

The OG Builder enhances the functionality of your application builder (I haven't used it). You can't use it if you don't already have the App builder as part of your orig. LV install.

Its great stuff.. give it a try. Open up the OpenG Commander for a lesson in good LV programming style.

Neville.

[Jim Kring]

I've been reading about OpenG this and OpenG that but I don't know where to start. There is very limited documentation explaining why anybody would want whatever it is OpenG offers . Maybe I suck at researching but I'm pretty sure I'm not.

Breifly, what is the advantage of OpenG other than it being "free"? Do I need to install Commander before I can use/install the OpenG Toolkit/Builder? Is there a chance that installing this software will break my current LabView program causing a reinstall? Will I need to package new run-time lib for sending out to beta testers that have only installed the main run-time? Currently I enjoy sending out updates of just a compiled exe to replace the old... I'm sorry for all of the questions but the OpenG websites I've visited haven't given me my answers. Would be nice to see some screenshots . Last question, if you don't mind; Is the OpenG builder a replacement for the LabView application builder or is it just a builder for wrapping vi's to send as toolkits?

The more I know, the more help I can be in the future. I plan to stick with LabView for life... eventually helping out with this OpenG stuff

To start, visit the OpenG Commander page and see the usefull links to get to the Download, Quick Start Guide and Manual.

OpenG Builder is also pretty well documented. It is a replacement for the LabVIEW Application Builder, but it does a whole lot more. You should note that you still need the LabVIEW Application Builder if you wish to build EXE's (OpenG Builder uses the LabVIEW Application Builder for this feature).

OpenG tools are very well written, and can be trusted about as much (hopefully more) than stuff coming out of NI -- we even have packages that patch bugs in vi.lib (VIs developed by NI that ship with LabVIEW). And, if you have any problems we are more than happy to help get you rolling -- we have a support forum here.

[PJM_labview]

...This program is rather large (an all-in-one tuner/datalogger for automotive EFI) and I don't have that nifty feature from 7.1 called navigator .

Did you actually click on the link I provide you in your post about the navigation window?

If you click on the "here", you will get a page (although now obsolete) with screenshot, explanation about this navigation window replacement and a download link.

Cheers

PJM

[JPrevost]

Did you actually click on the link I provide you in your post about the navigation window?

If you click on the "here", you will get a page (although now obsolete) with screenshot, explanation about this navigation window replacement and a download link.

Cheers

PJM

Looks like I need OpenG :worship: Thanks!

[JPrevost]

You should check out the Variant Configuration File I/O VIs from OpenG. These can read and write anything to an INI file (clusters, arrays, etc.). Download OpenG Commander and make sure that the variantconfig package is installed.

So I tried it today and an error popped up, "Please find the file 'Build Error Cluster___ogtk.vi"

Apparently this is the only vi I don't have and I used Commander to download the package. Is it missing or what's up? How to rectify the problem. If I don't get a reply soon here I'll post on the openG forum. I just thought it was more relevent here for future search.

[Jim Kring]

So I tried it today and an error popped up, "Please find the file 'Build Error Cluster___ogtk.vi"

Apparently this is the only vi I don't have and I used Commander to download the package. Is it missing or what's up? How to rectify the problem. If I don't get a reply soon here I'll post on the openG forum. I just thought it was more relevent here for future search.

make sure that you have the oglib_error package installed.

[Michael Aivaliotis]

So I tried it today and an error popped up, "Please find the file 'Build Error Cluster___ogtk.vi"

Apparently this is the only vi I don't have and I used Commander to download the package. Is it missing or what's up? How to rectify the problem. If I don't get a reply soon here I'll post on the openG forum. I just thought it was more relevent here for future search.

Just a quick thought. Many of the packages have dependancies. This means packages depend on other packages to be installed. I think the problem is that you need to install the oglib_error-2.2-1 package as well. The current released version of Commander does not have dependancy checking. This is a future feature.

[JPrevost]

Thank you, that was it

[PJM_labview]

So I tried it today and an error popped up, "Please find the file 'Build Error Cluster___ogtk.vi"

Apparently this is the only vi I don't have and I used Commander to download the package. Is it missing or what's up? How to rectify the problem. If I don't get a reply soon here I'll post on the openG forum. I just thought it was more relevent here for future search.

This is a dependency error. The package you are trying to use depend on another package.

You need to download the "oglib_error" package. To prevent further occurences of this error, I will strongly advise you to download them all.

See image below for a list of packages you migh want to download.

Cheer

PJM

[JPrevost]

I know I should post up my code to make this easier but I don't feel it necessary yet. My delema is this; I'd like to move all of my configurable data to a seperate dialog vi. How to go about this is just beyond me right now. I know how to pass in and out of vi's but my large application uses these user configure items in multiple places. Which means I'm using local's in a lot of area's. Not a TON, less than 4 of each but there are a good 20+ configurable user values from file paths to general numeric. In the main program, it's easy because right now the local variables are just that. If I move to a seperate vi for the configurables then there will be no more locals . Oh so confusing. Maybe I should just re-write all of my code in a better architecture because right now I'm getting overwhelmed just looking at it.

[Chris Davis]

I know I should post up my code to make this easier but I don't feel it necessary yet. My delema is this; I'd like to move all of my configurable data to a seperate dialog vi. How to go about this is just beyond me right now. I know how to pass in and out of vi's but my large application uses these user configure items in multiple places. Which means I'm using local's in a lot of area's. Not a TON, less than 4 of each but there are a good 20+ configurable user values from file paths to general numeric. In the main program, it's easy because right now the local variables are just that. If I move to a seperate vi for the configurables then there will be no more locals . Oh so confusing. Maybe I should just re-write all of my code in a better architecture because right now I'm getting overwhelmed just looking at it.

I've been using the OpenG Toolkit for awhile, in fact the INI config VI's is the first reason I started. For the last several projects I've used them on I develop a functional global to provide read and write access to the INI file's variables. This allows me to use any of those variables in any part of my program. You should probably check out a different architecture for your code to make less use of locals. You should be able to get by with one instance of a local for every control you want to update from the INI File. Simply call this case of a state machine to update from a change, or on startup. I personnally use a state machine architecture, which is probably the most popular. There are some shipping examples with LV, and probably some on this forum for you to research.

Chris

[didierj]

I know I should post up my code to make this easier but I don't feel it necessary yet. My delema is this; I'd like to move all of my configurable data to a seperate dialog vi. How to go about this is just beyond me right now. I know how to pass in and out of vi's but my large application uses these user configure items in multiple places. Which means I'm using local's in a lot of area's. Not a TON, less than 4 of each but there are a good 20+ configurable user values from file paths to general numeric. In the main program, it's easy because right now the local variables are just that. If I move to a seperate vi for the configurables then there will be no more locals . Oh so confusing. Maybe I should just re-write all of my code in a better architecture because right now I'm getting overwhelmed just looking at it.

For such problems, I usually create one ore more GOOP-Classes (in my case OpenGoop). This way all your parameters (attributes) are grouped in the class and you can create many reading/writing and processing methods with your attributes. You end up with just one reference (to the instanciated object) you pass through your vi's to access the attributes.

Also create a method that displays all your parameters in controls. At runtime you can modify them and with an "OK"-click they are written back to the object attributes and file.

If you follow the rules of GOOP-programming your program will be free of race conditions. For an example check e.g. Popup menu, or the ini-file-vis.

Didier

[Michael Aivaliotis]

Maybe I should just re-write all of my code in a better architecture because right now I'm getting overwhelmed just looking at it.

I don't think you need to re-write, just yet. I've managed to shoehorn-in gradual enhancements to software in a similer situation.

There are many file IO implementations to do what you want but I won't get into that. I've attached some code that implements an architecture for handling configuration data within your program. You have to fill-in the code for reading and writing to the actual config files. For this you can plug-in the openG config VI's if you want but that is not the point. The point in the attached example is that the locals are replaced by a functional global. Wherever you need to read from the config data you place this down and unbundle the required parameter, or all of them. You should only write to these parameters from the configuration window. The nice thing about this is you can place the functional global deep within any subVI's you may use and you can avoid wiring messes.

Download File:post-2-1138297260.llb

[David Wisti]

If there is an easier way to save cfg data and recall it I'm all ears.

While this doesn't slove your problem of loading locals from the INI file it does make saving and recalling INI files eaiser. This example uses strict type defs as the INI file format. It uses semaphores to prevent race conditions. This example uses open, get, set, & close methods. OpenG Toolkit and Labview 7.0 is required to run this example.

Download File:post-319-1138293429.zip

[JPrevost]

I don't think you need to re-write, just yet. I've managed to shoehorn-in gradual enhancements to software in a similer situation.

There are many file IO implementations to do what you want but I won't get into that. I've attached some code that implements an architecture for handling configuration data within your program. You have to fill-in the code for reading and writing to the actual config files. For this you can plug-in the openG config VI's if you want but that is not the point. The point in the attached example is that the locals are replaced by a functional global. Wherever you need to read from the config data you place this down and unbundle the required parameter, or all of them. You should only write to these parameters from the configuration window. The nice thing about this is you can place the functional global deep within any subVI's you may use and you can avoid wiring messes.

Download File:post-2-1138297260.llb

Thanks for that refresher. I knew my best bet was going to be using a LV2 global and to bundle everything into a cluster... just didn't occure to me to use the timeout feature :headbang: . I knew timeouts were good for something

[WMassey]

While this doesn't slove your problem of loading locals from the INI file it does make saving and recalling INI files eaiser. This example uses strict type defs as the INI file format. It uses semaphores to prevent race conditions. This example uses open, get, set, & close methods. OpenG Toolkit and Labview 7.0 is required to run this example.

I am working on a way to synchronize and protect read/modify/write access to a functional global containing state information. I had first thought of using a common semaphore created by the functional global but used by a re-entrant read/write vi one level up in the hierarchy. I soon discovered that a lower-level vi cannot create a semaphore reference and pass it up to a higher-level vi because the semaphore reference does not survive once the vi that created it stops running (<-- never mind; not correct; the semaphore does survive as long as the top-level VI continues to run). Anyway I'm not too proud to learn new ways from others and remember having seen the example you had posted did locking and unlocking of a share block of data so I thought I'd look into it more. I did look at it and, if I understand how the lock/unlock should function, then I don't think they are providing the protection they should provide.

This is how I tested. The test vi (LV v7.1.1) is attached (it makes use of subVIs found in the original example)

What am I missing?

Shouldn't the first lock cause the failure to occur in the second lock request rather than in the final release request.

Download File:post-2800-1141066053.zip

[David Wisti]

What am I missing?

Shouldn't the first lock cause the failure to occur in the second lock request rather than in the final release request.

The second lock times out after 250ms. So, the "Set Modified Data.vi" should be in a case statement with the timeout boolean. Actually, I've always used this style of semaphore to prevent a race condition but I've never set the timeout to anything but -1. If you did that in your example, the timeout would never occur and the program would wait forever. You example does show something I didn't notice, the "Acquire Semaphore.vi" doesn't return an error when there is a timeout. If it did, then I think your example would work as expected.

I too shamelessly stole this kind of protect read/modify/write access from OpenGoop object data store examples. Its not object based anymore and I never decided to take ini files from open/close to create/destroy.

[WMassey]

Your example does show something I didn't notice, the "Acquire Semaphore.vi" doesn't return an error when there is a timeout. If it did, then I think your example would work as expected.

Ahh that's it! I too made the assumption that it would return an error. That'll teach me to assume anything.

Thanks for clearing up the mystery. :thumbup:

[Phillip Brooks]

If there is an easier way to save cfg data and recall it I'm all ears.

Attached is a sample of a simple INI Functional Global I've used. It contains Initialize, Set, Get, Read INI and Write INI options. It also has an EDIT state where it pops up the FP to allow you to change the values.

The LLB also contains cluster based Configuration File functions that I wrote before I learned about the OpenG libs.

Saved in 7.0 for your convenience.

Download File:post-949-1141226044.llb