NI System Configuration API

[JensG69]

Nearly a year has passed since my last tests, but I still cannot apply an image to a cRIO/sbRIO where the user/passwords/user rights of the WIF-interface gets transferred from one system to another.

That's the source-code for creating the image (password has been deleted in the screenshot, the string was not empty). User rights have have been changed in the WIF interface (e.g. group "everyone" cannot change the IP-settings, User admin has a password).

Then I apply this image to a new system:

But all settings I've made to the WIF-interface are lost. I also get an error, code -2147220369, "The encryption passphrase when applying an image was not the same as when the image was created." But the passphrase were the same!

The system is running correctly after reboot, the only error is the missing configuration of the WIF-interface.

Tested with system configuration API, Version 5.4 (January 2013) and LabVIEW 2011 SP1.

I would love to see that this is finally working.

Jens

[Luke_W]

Hey Jens!

I just confirmed that this has been fixed in the 5.5 version of the System Configuration API which will be releasing this upcoming NI Week (Aug 5th, 2013). I replicated an issue similar to yours by removing all of the permissions from the 'everyone' group using the WIF. I took an image of this state, then formated the controller and reinstalled System Configuration. A quick double check in the WIF showed that the default set of permissions were granted to the 'everyone' category, as expected. Finally, applying the image taken earlier, I was able to restore the changes that I had made in the WIF (permissions were removed as before).

-Luke

[Bertha]

Is it posible to run these vis in the RT or is it just PC based? just wondering, so it can place its own image into a USB device. I tried with just opening a session and gives me an error

[JoshuaP]

Bertha wrote:

Is it posible to run these vis in the RT or is it just PC based? just wondering, so it can place its own image into a USB device. I tried with just opening a session and gives me an error

Some of the functions are supported on RT.  For example Find Hardware and all of the Hardware functions are fully supported on both Windows and RT.  We do not support executing some of the software functions like Format, Install, and Create Image are on RT.  However, you should be able to use the System property node and perform simple action like Save and Reboot.

The notable exception is Set Image.  It can be called on the new NI Linux RT targets like the cRIO-9068, but it is not supported on the VxWorks and Phar Lap targets.  So if you have one of your new Linux RT-based controllers you can definately place an image on a USB stick or pull one down using HTTP and then call Set Image to have the target reimage itself. 

[QFang]

Hi,

We currently make use of the "old" RT utilities to get CPU usage, used RAM and largest contiguous RAM information.  We call these frequently (sometimes 5 to 10 times per second) and include the information in our system log's as well as use it for self-monitoring (safe reboot if contiguous or free memory ever drops below 20% of full ram etc.)

We recently looked at migrating to the new API but found that the performance of "getting the cpu" takes on the order of 6 ms to return on the new API vs sub sub ms with the legacy call.  Same thing for the RAM information, except its even worse, 13+ms vs subsub ms.

I found this dedicated thread after I posted a thread on the RT forum.  That thread has the benchmark code in case anyone else can/wants to look at this.. Either we are doing it very very wrong or the VXWorks OS HATES the new API or the new API has some rough edges behind the scenes...

Obviously if asking for the CPU usage is a 6+ms call, then that could quickly add up on the overall CPU usage in a polling situation.. anyway, it just seems so strange that the new API is hundreds of times slower..

https://forums.ni.com/t5/Real-Time-Measurement-and/RT-System-Configuration-tools-arexcessively-slow/...

Comments, and definitely other benchmark results, and suggestions are very welcome!

[JensG69]

I'm playing again with applying an image of one sbRIO to another one - with changed settings within the WIF-interface of the sbRIO.

I found out a small improvement in comparison to my last extensive tests:

If I change the user-settings with in the security configuration (like adding additional users including passwords for these new users, changing the available resources for different groups), these settings can be transferred to another sbRIO under one condition: Do NOT change the default "admin" password which unfortunately happens to be an empty string.

As soon as I change the admin password, I can:

• still create an image of that system.
• I can still apply that image to another empty system, also in the end I get one error message:

Error -2147220369 occurred at nisyscfg.lvlib:Set System Image (Folder).vi:2060001

Possible reason(s):

NI System Configuration:  (Hex 0x8004046F) The encryption passphrase when applying an image was not the same as when the image was created.

• BUT the user-settings of the security configuration do NOT get transferred.

To summarize:

WIF interface allows extensive user settings, which can be very helpful for a deployed system BUT in order to automize the duplication of an RT-target (in my case an VxWorks based sbRIO) the admin password has to stay empty.

Jens

[Ranjani_R]

Hi Justin,

I have an application where in I self-calibrate all the instruments connected periodically.I use System Config API's and I am facing few issues

1)Is there a way to get the Driver Class used by the instrument? That is, when my device is NI PXIe 6556, the node should tell that its NI-HSDIO. I was not able to find a node and would like to know if there is any low level method that can be made use of?

2)When I use self-calibrate API, the instrument handle is creating a new session for the device which makes active sessions invalid if present. In short, my application can perform different operations on all devices(DAQs,HSDIOs,SCOPEs)independently and has a common module to self-calibrate any modular devices. So when I self-calibrate and go back to the independent modules, the session handles are invalid and I am not able to proceed further.

[Mads]

How safe is it to have two System Configuration API sessions work in parallel on the same (local) target? Is it OK as long as they never write conflicting values to the same property sets, or are sensitive to race conditions from reading the same values (other than references to hardware for example)?

I have a state machine that will set up a given network interface, monitor if it is successful in retrieving an IP address dynamically, and then make it fall back to a known static IP if not...Now, this piece of code would be nice to just copy and run for a second network interface...(partially because it has some long waits in it which will make it messier and/or slower to mix the two operations).

They will never write to the exact same properties (one will filter out and operate on eth0 references, the other will work on eth. This is on a Linux RT target), but is that still safe? When you do a save in the API, does it only save the properties that were changed, or does each session have a complete image of the setup when the session was started, and that gets saved as a whole, potentially wiping out changes done an instant before by a parallel session (I guess not, but I have not investigated it thoroughly yet).

I'm partially avoiding parallel *writes* in this case though, as all changes happen in a non-reentrant VI...but the other process might still open a session to read some properties and close the session again, potentially at the same time as I'm havin an open session writing changes (to the properties of the other ethernet interface) in the non-reentrant VI.

[Dan_Mondrik]

Given your approach and the things you're being careful about (not modifying the same resource; using a non-reentrant VI) then in general NI System Configuration ought to behave just fine, as you'd hope.

The one thing to avoid when using the same system session throughout your program is closing it while it's in use elsewhere in your program. One goal of the purple I/O wires was to easily facilitate their shared usage, but explicitly closing the session kind of thwarts that. In some cases it can result in the other caller getting an "invalid session" error. The preferred approach in this case is to close the "localhost" session only when your program is about to exit, or remove that code altogether and just let LabVIEW do that for you.

One other thing I'd like to clarify, since you're on Linux, is your term "the other process". If you mean that literally, then the shared session instance obviously isn't an issue, since sessions are per-process. Also note that (at least currently) the settings for both eth0 and eth1 are stored in the same file on the file system. So if you do have 2 processes modifying it occasionally, our implementation will (hopefully) notice that the file has been updated and re-read it before applying the next changes. But if your 2 parallel loops are different parts of the same LabVIEW process, it's always the process that made the change, so no re-reading is necessary.

[Mads]

The two "processes" in this are just two VIs running in parallell on the same Linux target.

They each open their own session with the Initialize session VI, they do not get the session as an input from the outside...So I thought they had unique sessions, but I see the session output, if typecast to a string, is identical. So that means that I should not really close any of them, because it might invalidate the session used by the other one as well?