LabVIEW Real-Time Idea Exchange

About LabVIEW Real-Time Idea Exchange

Have a LabVIEW Real-Time Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. Browse by label or search in the LabVIEW Real-Time Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  3. If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW Real-Time Idea Exchange. Be sure to submit a separate post for each idea.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
SFK

Allow selection of ethernet port for RT target discovery/deployment

Status: Completed

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

 

 

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

14 Comments
JoshuaP
Active Participant

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
Active Participant
Status changed to: Completed

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

 

 

Deborah Burke
Senior LabVIEW Product Manager
Certified LabVIEW Architect
National Instruments
MGiacomet
Member

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

 

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

JoshuaP
Active Participant

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.