03-19-2012 02:14 PM
The System Configuration API cannot dynamically reconfigure network settings - the network settings are not actually applied to the target until its next reboot (I should have been more clear, almost ALL possible network configuration is done at boot time, with the one exception of lease renewal). What the System Config APIs do is set the proper values in the INI files, so that on the next reboot everything works as expected. Therefore, when you set the IP settings they are not applied immediately, they are applied on the next reboot - if you find that DHCP doesn't work, you cannot then set the IP address and expect it to work immediately.
RT must have an IP address before it allows any application to run.
03-19-2012 02:38 PM
I definitely want to request such a feature...but what is the proper channel?
There are two paths. One is the idea exchange, which is where we get a lot of great user suggestions and turn them into features. You can get to the Idea Exchange via http://www.ni.com/ideas and post your suggestion. There is no guarantee that your idea will be implemented as a feature, it depends on how "popular" the feature is. I will tell you that more investigation will need to be done before doing anything with your suggestion, as I can see a lot of problems with the initial idea - it needs to be fleshed out a lot more.
The second path is a Custom Engineering request, we can guarantee that your feature gets R&D face-time, but it's not free. If you decide to do that, you must contact your sales rep for the area you're in, and they can help you with a custom engineering request.
03-19-2012 02:50 PM
03-20-2012 12:02 PM
I was able to set aside some time and test this behavior, and I have it working. The only difference is that you don't check the "Halt on TCP/IP Error" box. If you set the ni-rt.ini token:
What happens in this case is if DHCP fails, you will get the message:
Unable to configure the primary network device.
The primary network device will not be configured, but the System Config API can still see the network devices in the system (I didn't think it would be able to). You can then use the System Config API to configure the network devices like you have been doing and it works the same.
03-20-2012 12:33 PM - edited 03-20-2012 12:37 PM
This sounds perfect, Ill test it tomorrow when I have the gear. But this possibility will be lost in 2012 you say?
03-20-2012 12:50 PM
Yes, we added the "feature" in RT 2009 when we officially moved to supporting AutoIP (DHCP with LinkLocal fallback) and it's been 3 years since doing so with you being the first one who is documented as needing the mechanism to disable LinkLocal. We are also doing a LOT of maintenance to the network infrastructure components for RT 2012, and this feature was "removed" from VxWorks and "not reimplemented" for PharLap - it doesn't make much sense to complicate our code base to keep in "what if" tokens and behavior that will not be used.
It is too late to re-add this behavior to RT 2012, but I have filed CAR 344502 to have this behavior re-added for RT 2012SP1. You can watch the readme and release notes for RT 2012SP1 to see if the CAR makes it into RT 2012SP1, or reply back to this thread in November to keep it on our minds for RT 2012SP1.
04-11-2012 08:10 AM - edited 04-11-2012 08:14 AM
It took some more time before I could test it, but now I have done so and the results were not good;
I added the section:
The result is that the RT Application never gets launched when DHCP is offline. Yes, it does not fall back to link local, but the end result is the same as when it did - status LED starts to flash 4 times indicating a crash and no app is launched (with APIPA it just crashed the same way, but then due to the proxy ARP conflict).
What I expected and hoped for was that it would launch the application. We would then get up and running, and access on the secondary NIC (we would for this particular app also get NIC 1 up and running because the application would automatically reconfigure it to use static IPs...but that's the longer story).
You mentioned that you had tested it, but perhaps you just checked that you could manually reconfigure it after such a bootup, not that it started the application, which could then reconfigure the NIC settings using the System Config API?
Or are there other keys that will have to be set? Is there e.g. andything in the TCP_STACK_CONFIG section that must must be changed or added, except for the Halt_On_Error which is set to False?
04-11-2012 11:23 AM - edited 04-11-2012 11:24 AM
My test setup was as follows:
LabVIEW Real-Time 2011SP1
My test process was as follows:
I did not attempt to use the System Config API to reconfigure the network settings, but if the startup app loaded and the System Config API can detect the network devices in the system then I considered it an exercise to the reader to complete the steps.
Does this not work for you the same way?
04-12-2012 07:02 AM
Different story here I'm afraid:
Fieldpoint 6.0.9 - Aug 2011 (LabVIEW Real-Time 11.0).
1. Installed a simple application that outputs data on the serial port - and used this to check if the application is started.
2. Added the nolinklocal key and verified that the Halt on TCP checkbox was unchecked.
3. Restarted the controller with NIC 1 set to DHCP and NIC2 set to static (the latetr not connected). - application started OK (data on serial port)
4. Disconnected the controller from the LAN and connected it to a laptop instead.
5. Restarted -> No application started (no traffic on serial port), and status LED indicates that it has entered Safe Mode.
6. Reconnected to the LAN (with DHCP server) - boot up fine.
7. Disconnected again (no laptop) ----->> Crash and safe mode again, no application launched.
The nolink key is definitely registered as it would otherwise go to link local, but it never launches the application so nothing is gained. Any ideas?