NI System Configuration API

[Justin_E]

Hi Benjamin,

What version of System Configuration do you have installed? If it's anything less than 5.0, I'd recommend upgrading:

http://joule.ni.com/nidu/cds/view/p/id/2613/lang/en

How are you searching for the ethernet cDAQ device? Is it on your local subnet? Have you tried using the Find (Systems) VI without any session input?

[Benjamin_C]

Hi Justin,

I am using 5.0 version. I have three cDAQ-9181 behind a switch connected directly to a LAN port. They are set with static ips. I am on Windows 7 and the firewall is disabled.

If I run a test with all the cDAQ devices added to the system and the cDAQ devices online :

- The list returned by Find (Systems) doesn't include all of the cDAQ devices.

- The list returned by Find (Hardware) is OK.

If I run a test with all the cDAQ devices added to the system and the cDAQ devices offline :

- The list returned by Find (Systems) includes offline devices (even if I select the "only if online") parameter.

- The list returned by Find (Hardware) includes offline devices, but the "IsPresent" properties returns the correct connection state.

If I run a test with no cDAQ device added to the system and the cDAQ devices offline :

- The list returned by Find (Systems) doesn't show the offline devices.

- The list returned by Find (Hardware) doesn't show the offline devices.

If I run a test with no cDAQ device added to the system and the cDAQ devices online :

- The list returned by Find (Systems) doesn't show all the online devices.

- The list returned by Find (Hardware) show no online device.

I don't have the opportunity to test on another PC for the moment.

[zlavick]

Hi, like sachsm have problems with "Rename Alias.vi":

     Error -2147467259 occurred at nisyscfg.lvlib:Rename Alias.vi

But i'm using latest DAQmx (9.4) and System Configuration (5.0).

How can i get the reason of this error in my case and can it be solved? More details in this post.

[zlavick]

Oh, three days and i hack the bug. It is the problem with RTSI Cable.

Cable was connected with Dev1 - NI 6229 (real) and Dev2 - NI 6221 (simulated).

It was possible in previous versions of MAX, but in 5.0 i can't do this.

So, when the devices in cable have been deleted everything became good.

But with two simulated devices in RTSI cable i'm getting '5 minutes timeout' and RT controller hangs, even remote reboot can't be executed. Only hard reboot hepls.

I can't test with two real devices connected via RTSI, but it seems to me bug will be there too...

[John.P]

Hi,

I have an issue when creating an exe using the system configuration API's.

The PC application allows my customer to update all the files on a cRIO using custom FTP functions, the code then uses the system configuration API to programatically set the second ethernet port on the cRIO to EtherCAT.

This all works correctly under my development environment where I have the NI dev suite installed + most of the NI drivers.

I have built the application into an exe and attempted to run it on a computer with the only the LV runtime engine, NI-RIO & NI-Daqmx installed.

The first issue was the functions required the "nisyscfg.dll" which was not present on the computer.  I located this on my development machine under Windows/system32 and included it with the build.

The application then loaded and was happy but when the VI that calls the system config VI's is run, the code returns an error stating "the code called by an external library returned an error".

I am hoping you can provide a list of the required software / drivers / packages that are required to use the system config API as part of an exe.

Does the customer need RIO? DAQmx? or just the run time engine and a few extra dlls?

Thanks.

[John.P]

Apparently you just need to install MAX and the appropriate libraries are installed, this is an option when creating an installer from a LV project, but there is no stand alone installer for MAX.

However this:

Run time for system configuration: http://joule.ni.com/nidu/cds/view/p/id/2614/lang/en

is what I should have found in the first place.

LabVIEW runtime + this runtime resolves my issue - posted in case anybody else failed to find this.

[Dan_Mondrik]

Just to make it clear for other folks - the NI System Configuration runtime is what you need to deploy for these VIs.  MAX is a superset that includes NI System Configuration API but is a bit larger.  The only VI on that palette that requires MAX to be deployed to the target system is Generate MAX Report.vi.  All other VIs work fine with just the NI System Configuration runtime.

[Mads]

I have been using the system configuration API for a while now on a project that requires a cFP-2220 to behave rather unconventionally; its network configuration is supposed to be possible to manage from a DHCP server, but that server is only online occationally - so if it restarts and the DHCP server is offline it has to reconfigure itself to a static address using the last received address...In addition its secondary network interface should be semi-dynamic too (there is no DHCP client on NIC2, but we've been allowed to set is address based on the address on the primary, with an offset (placing it on another subnet)). So - the system configuration API is used to cycle from between static and DHCP addressing. With the most frequent case being the sequence  static->dhcp->static, which is what will happen if the DHCP server is offline (but the secondary NICs static address is found to be OK...otherwise you would get 4 steps).

We run this "NIC Manager" code at the start of the RT-app and on most controllers it works fine in all connection-scenarios...but then we have two controllers which got into trouble with this code:

The first case was a controller that would refuse to start if it was connected on both network ports. This problem was linked to a left-over MAC section in the netconf.ini file (garbage sections can occur due to a bug in the RT Replication VIs reported in CAR 190786) - removing such a section from the start of the INI-file fixed the issue, but we cannot replicate the issue on any other controllers by adding such a section(!).

The second case is a problem we have yet to solve (especially difficult because we currently do not have access to the failing unit); this controller will behave properly inn all but one case; if its primary port is connected to our customer's routed network and their DHCP server is offline (i.e. the most normal condition)...Connect port 1 to a laptop instead and it runs fine, start the DHCP serrver its fine etc...It reboots 3 times so the first two steps going from static to dhcp seems to execute (not verified for sure though), but on the third reboot (static) the status LED of the cFP-2220 starts to flash 4 times indicating a software crash. No netconf.ini file corruption is present in this case, and it is a bit different than the first case in other ways too...But in both cases the NIC Manager is causing the weakness, without that everything works always...

I have attached the NIC Manager code here and hope that some of you have the time to review it in regards to this behaviour. Could it be a race condition, e.g. due to the fact that we execute the restarts immediately after reconfiguring the network settings for example? Or are there incorrect actions or weaknesses in the code that could make some controllers be sensitive to the network topology, but others not? Are there known issues with the API that could cause this?

[Mads]

Turns out the NIC manager / System Configuration API was not causing the crashes - it's the in-built DHCP client and its fallback to link local addresses that caused a crash in the controller when combined with Proxy ARP on the router (we did not know proxy arp was enabled on the customer's network, nor that it would have such a far fetched consequence).

This prevented the RT app from ever launching and getting the chance to reconfigure the NIC to static...

http://forums.ni.com/t5/FieldPoint-Family/Problematic-fallback-to-link-local-how-to-avoid/m-p/191550...

I wish someone from NI would take a look at these issues.

Mads

[dwisti]

I'm still using the System Replication Tools in my own custom application.  They have served me well over the years and still work just fine.  I started to research this API and noticed a feature missing.  The replication tools reported their status in:

SystemReplication\_SubVIs.llb\ProgressUpdate.vi

This VI was just a simple type2 global with an appended string of the replication tools status.  It works perfect for progress info.  Does this new API have a method or property to get this string?  The process of retrieving or setting a target image is a lengthy process.  It would nice to be able to report the status while imaging targets.