NI Labs Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

NI System Configuration API

That's right, Mads. Keeping this session open is your best bet.

0 Kudos
Message 81 of 96
(5,213 Views)

Here is an unexpected behaviour (I am tempted so say bug right away, but let's see what you guys think) I spent a lot of time figuring out.

If I try to reconfigure a network interface by writing to the System hardware Property node, the changes will be voided if the property node also does a read of the current link speed (other properties do not display this disruptive effect). Here is an example:

The following works fine (an sbRIO 9651 changing its IP etc of its Eth1 interface:

works fine.PNG

But add a read like below, and the property writes are completely ignored:

Reading property voids change.PNG

Note that using a separate property node instead will not work either. The only way that will work is if you do the read prior to any of the writes.
I have not checked yet if this is unique for the secondary interface of this particular sbRIO....I have a cRIO-9030 I can test it on later though.

(On a side note the working example will not update the web interface of the device with the new setup (even though it is in fact effectuated) unless I take the Eth1 interface down and up again using system exec calls ip ip link set, something I already happen to do anyway though because otherwise the host devices will not know to refresh their ARP lookup tables).

0 Kudos
Message 82 of 96
(5,213 Views)

Yes, sadly this is a known bug 462874. It is not unique to this situation. After setting properties, you must immediately call Save before reading further properties.

0 Kudos
Message 83 of 96
(5,213 Views)

Ok, thanks. That is quite nasty though...Is the bug scheduled to be fixed soon?

0 Kudos
Message 84 of 96
(5,213 Views)

Having ruled out the issue related to the bug in the API where reads wipe out any writes I'm left with one issue when it comes to self-reconfiguring network interface on an sbRIO-9651; even though the API and web interface reflects the change that has been run through the System Config API (changing the mode from DHCP to a static IP), it just does not come into effect until you unplug and plug the network interface. This is on a clean software install, no changes done to anything in the OS etc.

So if I for example programmatically change the configuration of Eth1 from DHCP to static and save it, there will be no contact on the given static IP, and wireshark will show that the device is still sending DHCP discovery messages, until Eth1 is unplugged and replugged (an effect I previously tried to trigger programmatically by doing a sudo ip link up/down on it, but that does not seem to fully effectuate the changes either).

It's a bit unclear if this would be better suited for the SOM or Linux RT communities, but hopefully everybody who's potentially linked to the issue will see it here...

0 Kudos
Message 85 of 96
(5,213 Views)

Ok, so I got an answer about the System Config API not fully updating the network config on its own (even though it does not flag a need for a restart for example...) over at the Linux RT community: https://decibel.ni.com/content/message/103871#103871

The lack of refresh is due to user restrictions on the application. I hope this will be addressed in an upcoming version (without the solution being that the need for restart flag is set).

0 Kudos
Message 86 of 96
(5,213 Views)

Hi Justin_E

I would like to know whether I can configure NI (scan netwrok devices and populate) using DAQmx APIs. It seems like the API I am using in my C++ program - DAQmxGetSystemInfoAttribute - is not giving me any data back. I am trying to scan and detect the NI devices on the network using my C++ program and I have only the basic NIDAQmx Runtime installed on the system. IS this possible at all? Or are there any low level NI system configuration APIs available?

Thanks,

Jyothi

0 Kudos
Message 87 of 96
(5,213 Views)

Trying to rename the GPIB-device aliases or 'GPIB Interface ID's in order to rearrange them because of how some old software (Fluke METCAL) knows only how to use 'GPIB0'.

I can do this manually from NI MAX just fine:

MAX_GPIB_small.jpg

However when I try to use the Rename Alias.vi get an error:

rename_alias.jpg

Max version is 15.0.0f0. NI System Configuration 15.0

Labview 2015 (64-bit), NI-DAQmx MAX Configuration 15.0.1

PS: Yes, I've also tried the standard example Rename Aliases.vi - it reads just fine but gives the same error when trying to write.

0 Kudos
Message 88 of 96
(5,213 Views)

In response to fiaf: It's not the version of NI System Configuration that matters, it's the version of NI-488. They added the ability to programmatically rename the alias/identity only in their 15.0 version, so you should update that. Good luck!

Message 89 of 96
(5,213 Views)

Resolved! Thanks!

This was indeed the issue. For some reason I had updated all other NI software to v15.0 - but missed the 488 driver that was still at 14.0. Now I can programmatically feed any GPIB-bus to METCAL as 'GPIB0' which according to Fluke is hardcoded and cannot be changed :3

0 Kudos
Message 90 of 96
(5,213 Views)