Allow selection of ethernet port for RT target discovery/deployment

[SFK]

Many developers have the primary ethernet port of their development computer reserved for the corporate intranet/internet access.

Unfortunately, MAX and other tools like RT System Deployment Utility expect the targets to be connected to the same primary port for initial configuration, because they do not allow the specification of a local IP on which to exchange the UDP configuration packets.

Being able to select the ethernet port on which the RT system is connected, e.g. through a ring control populated with all available NICs and their local IPs, would facilitate devolopment enormously in such constellations, because the developer would not need to switch cables and IP configurations every time he needs to reconfigure the RT system.

Thanks,

Sebastian

[JoshuaP]

I'm not sure what version of MAX you are using, but MAX 4.7 had a few known issues when discovering targets.  Many of these issues have been fixed in MAX 5.0, so I would suggest upgrading if you haven't already. 

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

If you are still running into issues I would suggest contacting support.

[Deborah_B]

Hi Everyone,

With the new NI Linux Real-Time based controllers released at NIWeek this year we include a USB Device port, which I think addresses the pain described in this post, allowing you debug/modify the target without messing with your existing Ethernet infrastructure. For more information you can read here: Ethernet over USB Connection for Simplified Target Configuration, Debugging, and Maintenance

Best Regards,

Deborah Y.

LabVIEW Real-Time Product Manager

[MGiacomet]

How can this be "COMPLETED"???...

How about the existing (non-Linux-based) systems already purchased from NI? Orphans?

[JoshuaP]

As I previously mentioned, newer versions of NI System Configuration and MAX try to send UDP broadcast traffic out all ports so there is no need to specify a port.  The only exception is on some older XP machines, where Windows fails to send the data out every port even though that is exactly what we specify.  

For the newer Linux-based systems we moved away from UDP entirely to web services and SSH, which can't be easily supported on non-Linux systems.