Should I use .INI or .XML config files on cRIO?

[JimMacD]

I'm looking to make a configuration file for an application running on a cRIO-9022. It will contain a small amount of configuration data (like numeric offsets, file paths, and IP addresses). I have 2 questions:

1) Which file format should I use (.ini or .xml)? I have used .INI in the past because it is human readable/configurable with notepad, but it seems like .xml is becoming the new standard

2) I would like to be able to modify config parameters on the PC that connects to the cRIO. What is the best way to modify the config file if it is stored on the cRIO hard disk (FTP the file to PC, make changes, FTP back? Network Streams?)

[Scott_A]

I tend to use ini files for adding special configuration tokens.  I just use Windows Explorer to get to the file location and edit it from there.  If you have not done it before you can get to the top level of your cRIO by putting the following into Windows Explorer:  ftp://x.x.x.x         (where x.x.x.x is the ip address of the cRIO)

[JÞB]

the .ini files are faster to load into your app and directly human readable.  However, they do have limitations-  It doesn't sound like you are nearing what a .ini can do and is designed for

[JimMacD]

Thanks for the info.

Any clever ways of accessing and changing the Config File data from a LV application running on a PC that doesn't require manually editing the file? I want the operator to just be able to click a button that says "cRIO Config", open a dialog, and change the values from there.

[JÞB]

---

@JimMacD wrote:

Thanks for the info.

Any clever ways of accessing and changing the Config File data from a LV application running on a PC that doesn't require manually editing the file? I want the operator to just be able to click a button that says "cRIO Config", open a dialog, and change the values from there.

---

uhm.... Yes!

In This Post I show a bit of my hand on just exactly what I keep in a ini.config file (wel,l 1 section of a config file)  It would be nearly idiotic of me to not provide a Config editer since there are numerous Enum type defs in the delimited value for each key.  so since I, as the developer, know what sections (and possibly keys) are there I can read the file and load them to indicators on a config editor GUI.

I've actually done this two ways-

1) a seperate app that only "admin Engineers" know the location of "Launch Config editor.exe.

2) In the application referanced above I have a button that opens a MODAL panel to edit the file (remember- I know what is in the file).   Users need permissions (Users- Passwords and permissions are kept in a config file, of course!) to even display the "Edit Sequence" button. but the "super user" can edit the step parameters. 

HINT: one of these "Steps" loads a xml file to expose telnet commands and config for the uP on the DUT.   I expect the firmware on the Linux DUT will change in the future and did not want to rebuild my app whenever a typo was fixed in a command line tool.  BUT, since there are "special characters" that do not fit nicely into a .ini I exposed the telnet commands and line ends IP address and the login script  in a xml file.

I know this did not directly answer your question!  but It should provide some food for thought.

If you can share your data structure- I can be more specific. 

[JimMacD]

Jeff, T

[JimMacD]

Jeff,

The data structure will be less complex than what you have shown in that post. Here is a sample of what I'd be looking to include:

-Section 1- (cRIO TC Offsets [numeric dbl])

TC1: +1.1

TC2: -0.9

TC3: 0

TC4: +2.1

...etc...

-Section 2- (cRIO IP Adresses [string])

HMI Address: 192.168.1.1

Server Adress: 192.168.100.100

-Section 3- (Data File Paths [path])

Data Folder: c:/Data

ThumbDrive Data: u:/Data

Error File: c:/Error.txt

-Section 4- (Global Offsets [numeric dbl])

Number of Cells: 3

File Write Time (minutes): 0.5

On the config. editor screen, I would limit who can change certain parameters. For example, engineers could change the TC offset values when performing a calibration to verify TC readings. However, an Admin would be the only person to change file paths and IP adresses.

Your post did not seem to have a RT target in the program, everything was running on a computer. This would make your file IO to open/modify the config file much easier. I'm still looking for a way to acomplish this with the RT target; my first thought was

-Open Config Page on Host PC

-Command to FTP the config file from cRIO to PC

-Open, modify, save config file

-Command to FTP the Config file back to cRIO

here I would have to come up with some logic that re-reads the file and updates config parameters (stored in a FGV) depending on which values are changed. (i.e. update values if TC Offsets are changed, however changing an IP Adress may require a restart of the cRIO)

[JÞB]

---

@JimMacD wrote:

Your post did not seem to have a RT target in the program, everything was running on a computer. This would make your file IO to open/modify the config file much easier. I'm still looking for a way to acomplish this with the RT target; my first thought was

---

Quite right- but the idea was to provide a config editor GUI-  On an RT target you have a few options.  I would DEFINATELY use an action engine on the target to maintain the "current parameters" with actions to include "read from file".  The .ini access is much faster- but you need to write your own parser for complex data (I think OpenG has some good utilities for cluster to ini conversions but don't quote me on that -I haven't used an openG function in years)

On the other hand I think I would store the config file itself on the host to make it easier for a user/operator/developer to maintain.  The RT OS only needs access to the file during initialization and a FTP call to the config file isn't too time consuming for this single operation.. A "File Stale" shared variable can be employed (dameon on the host) to force the AE to reload dynamically in the rare event that you want to update "current Parameters" on-the-fly without stopping the RT application but, for most use cases I'm betting the RT app is down while you are updating the config data and this is just overkill

[JimMacD]

---

@Jeff Bohrer wrote:

 

On the other hand I think I would store the config file itself on the host to make it easier for a user/operator/developer to maintain. 

---

My only reservation to having the config file on the Host is that the RT system will be starting up/running without a Host computer connected to it. I want all important information critical to the RT application to be local for this reason.

[JÞB]

---

@JimMacD wrote:

---

@Jeff Bohrer wrote:

 

On the other hand I think I would store the config file itself on the host to make it easier for a user/operator/developer to maintain. 

---

My only reservation to having the config file on the Host is that the RT system will be starting up/running without a Host computer connected to it. I want all important information critical to the RT application to be local for this reason.

---

That would make it a bit hard to initialize then