I've got a situation in which I would like to configure the Daq on a cRIO from a configuration interface on a Windows host. In particular, I would like to get IO Variable addresses for all the Scan Engine channels configured on the cRIO. The configuration program runs on the Windows host and cannot deploy any deamon to the RT that could query the hardware. It needs to run as if the cRIO is not present.
The configuration program is part of the same project as the cRIO, so my thought was to parse the project to find the relevant items. Here's a post that does something very similar:
However, this has several problems. This example was written in 2011. I'm using 2015. Apparently the properties changed since then. The "Find Children" (which is no longer named "Children ") does not give me the chassis reference on my 9068. Instead, I was able to use the "Owned Items " property, which gives a bunch of things, and then I search the TypeString of those things until I find one that is "Chassis". Fair enough. Then the Chassis ref gives me the Modules, and the Modules give me the channels. Sounds pretty good. But all I get are the channel names. I can't seem to find any properties that define the module type or the IO direction. E.g. I would like to know if a variable is Boolean or Real, and if it is an input or output channel. You can deduce that from "standard" names, if the project hasn't been edited to give them creative or meaningful names. But it seems like there should be a way to find these properties directly.
Solved! Go to Solution.
I think parsing the project tree is a pretty shaky strategy as you had to find out already. AFAIK the NI sanctioned way for this kind of thing since a few years already is to use the System Configuration API. Yes it is a pretty involved API and it takes you a bit of time to find out how to get at the specific information that you are interested. Luckily there do exist a few examples that you can use to start with.
Thanks, Rolf. I'm somewhat aware of the System Config API, but it had slipped my mind when starting in on this. I'll take a look at it and see what I can do. I'm guessing that this will be much more robust, with the one caveat that you'll have to be connected to the RT when executing it. But in my case, that shouldn't be much of a problem.
Offering another idea...
While I have not done it recently, I have hacked the files on the target.
FTP the config related files to the Windows side, parse as needed ad then write the modified file to the target.
Since I have not done it recently my code and details are most likley dated.
The Replcation Toolkit now does what my code used to do.
Thanks, Ben. Sounds a bit hairy, but I'll keep it in mind as another option.