04-01-2015 08:06 AM
That's right, Mads. Keeping this session open is your best bet.
05-12-2015 06:44 AM
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:
But add a read like below, and the property writes are completely ignored:
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).
05-12-2015 07:39 AM
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.
05-13-2015 02:29 AM
Ok, thanks. That is quite nasty though...Is the bug scheduled to be fixed soon?
05-15-2015 08:46 AM
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...
05-27-2015 03:04 AM
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).
09-16-2015 01:33 AM
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
11-06-2015 02:08 AM
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:
However when I try to use the Rename Alias.vi get an error:
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.
11-06-2015 08:26 AM
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!
11-09-2015 01:55 AM
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