LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UDP Normal and Multicast Not working on Linux RT based NI RT Systems

Solved!
Go to solution

I am a very long time user of cRIO and sbRIO systems and am now seeing that UDP Multicast functions don't work with the Linux based RT OS's.

 

I've never had problems with the VxWorks RT systems, and now reliable, proven UDP multicast code no longer works. I don't get any errors from the RT Send UDP Multicast - I simply GET nothing = timeout on the UDP read from my Win7 host side.  My cRIO system has a static IP. My firewall is off and I don't have any malware of virus applications running that could be blocking.

 

If I run the RT code from a Win7 laptop - it all works fine. TCP/IP works on the RT, but no UDP data is received.

 

What's changed?. When I look at the forums, I see this quite bizzare post about "Issues with UDP and Static IP addressing of the RT system"...huh?

 

http://digital.ni.com/public.nsf/allkb/BC971735E7A2A02B86257DE8006D101D

 

This clearly appears to be an NI implementation problem, I really don't want to hack the linux OS to get these basic functions to work. 

 

Any help would be appreciated, I don't see any 'master list' of what is supposted to work in RT/FPGA sbRIO RT Software.png

 

I also found this post which indicates my same observation with VxWorks and Linux NOT is here...and unresolved.

 

https://decibel.ni.com/content/message/106039?tstart=0

 

 

0 Kudos
Message 1 of 29
(6,181 Views)

I'm confused as to what your concern is.  The solution to this problem is to add the rule.  There's two ways this can happen:

 

1) You can manually add the rule

2) NI can add the rule in their implementation

 

You're wanting NI to resolve their "implementation problem."  If they do this, they'll use the same "hack" you're not happy with.  That really leaves you with three options:

 

1) Sit around pouting until NI implements something you won't be happy with even though it resolves your issue

2) Use about thirty seconds now, resolve the issue, and sit around pouting because you resolved it the same way NI would

3) Use those same thirty seconds now, resolve the issue, and go on happily knowing your issue no longer exists.

 

Why are we choosing option 1?

0 Kudos
Message 2 of 29
(6,136 Views)

natasflw,

 

Because I've been down this road before with the NI SOM, attempting to hack the Linux to allow an FTDI-USB interface to work for client project, after a full day. it did not work and we had to abandon this solution completely. Why am I bothered by this?.

 

There's been alot more issues since Ni went to Linux for RT.

 

1. NI clearly stated that by RT version 14 they would support FTDI-USB interfaces...my client read this and Believed it.

2. It did not work, even with RT version 14.5.

3. The few linux hacking instructions for fixing it, proved completely non-relevant, because the Linux implemtation on the SOM is not the same as outlined, and fact the \Dev Directory is LOCKED on the SOM...WebDav did not work, even though the admin permissions were added. I am not Linux conversant, and it's not stipulated as a requirement to deploy labview applications on RT systems.

4. I'm a consultant so I had to bill the client for time spent working on something I should not have...that did not work at all. A black mark by the client about using NI hardware again -- thanks, throw another log on the "LabVIEW is not a real programming language" fire.

 

There is no disclaimer that one would need to hack the Linux OS to employ basic network functions of the cRIO line, I've since tried this on two RT systems: cRIO-9073, & sbRIO-9636; the UDP does not work on them. I don't normally have to Hack the Window registry to get LabVIEW applications to function.

 

To your point: It's a simple fix...then why dosen't NI do it ONCE...so everyone else doesn't have to waste time doing it over, and over again!.

BTY: It's not just the time to implement the hack...how about the time I spent figuring out that it's not a bug in the code.

 

 

Worse this problem as been around for quite awhile: (note the workaround is "N/A")...

 

LabVIEW 2014 Known Issues from NI.com

LabVIEW 2014 known issues.png

 

Regards, Thanks for at least some reply!. 😉

 

Jack Hamilton

 

 

 

0 Kudos
Message 3 of 29
(6,119 Views)

I'm not trying to suggest it wasn't frustrating to reach this point.  I'm also not sure why it isn't changed to the implementation.  I'd think it'd make sense to do so.  But, I'm not sure what else it would adversely affect.  I can't think of anything that it would.  I also don't want to claim it's impossible for it to do so.

 

From your post and the linked KB, it sounds like you've found the solution.  Have you tried it and it didn't work or did you want to avoid trying it based on your perception of it as a "hack"? I use the word in quotes as you're being a tad liberal with it.  It's similar to calling your option to use a static IP a hack.  It'd be similar to claiming you'd need to hack Window to ensure your Host PC is on the same subnet as your cRIO to communicate with the cRIO.  It's not hacking as much as it's configuring network settings.  I can be demanding.  But, I don't think I'm ever going to expect anyone to provide an out of the box solution for every possible network configuration and call anything I change a hack.

 

It sounds like you're letting another frustrating issue cloud your judgement on this one. 

0 Kudos
Message 4 of 29
(6,102 Views)

Natasftw,

 

I concede that we all need to hack at bit. I also look at the price point for NI hardware and software...this is not in the Audrino domain, where the low-cost is offset by the amount of 'customization' to acheive one's end.

 

Also, the cRIO's, FlexRIOs and sbRIO's are closed systems dedicated to LabVIEW code deployment...so I don't expect to have to modify the dedicated OS at all to provide for a high level LabVIEW function to operate as intended.

 

Is not one of the tenents of LabVIEW is that's it abstracted from the OS? So I can deploy high-level functions without regards to how the OS actually implements this?...

 

This breaks the LabVIEW paradim and is the reason for my shock - I do not expect to have to modify the OS to implement such features. I am not a Linux guy, nor really interested in reading and learning about Linux. I've already had to read thru a 180 page manual to understand a radio interface, and a 400 page manual to understand a high-precision Avionics GPS...I choose LabVIEW so I don't have to read how to open a UDP port in Linux. I did not have to when RT was on VxWorks.

 

I've not tried the line CMD...But I will...and post back to the forum.

 

Regards, thanks again for the dialog!, I do appreciate it...NI needs to understand how these omissions, are construded differently...Some people don't care, some do. I've been using NI products and coding in LabVIEW for 28 years.

 

Jack Hamilton

 

0 Kudos
Message 5 of 29
(6,089 Views)

Hi Jack,

 

I've read through this thread a few times, and now I'm confused.  I'd like to straighten out a few details.

 

What specific HW are you using? The screenshot in your first post shows an sbRIO-9636. You also state that this is a Linux issue and you have never had issues with VxWorks. 

 

The sbRIO-9636 is a VxWorks based controller. 

 

Later in the thread you said you tried this on cRIO-9073 and sbRIO-9636 and UDP Multicast DID NOT WORK on either target.  Again, both these targets are VxWorks targets.  No Linux target model number has been referenced with the problem behavior (aside from the comments regarding SOM and past experience with USB-FTDI that I would still like to resolve).

 

In the known issue you referenced (CAR 202192), it explains that the UDP behavior IS consistent between Win 7, Vista, VxWorks, AND Linux. Only XP and ETS (Pharlap) broadcast UDP on all NIC interfaces while all the other OS's broadcast on the default NIC. In addition, this CAR references 'broadcast' and I thought your original issue was with 'multicast'? This CAR doesn't prove that Linux is doing something differently than VxWorks (it states the opposite), and I'm concerned that you are not even using a Linux based controller.  I want to make sure we are on the same page solving the same problem, and not assume that Linux is the variable and therefore the problem.

 

Regards,

Spex
National Instruments

To the pessimist, the glass is half empty; to the optimist, the glass is half full; to the engineer, the glass is twice as big as it needs to be has a 2x safety factor...
0 Kudos
Message 6 of 29
(6,075 Views)

Hello Spex!,

 

Now I'm confused. How does one tell from the software tree in Max that the OS is VxWorks or Linux, should I care?.

 

Can you open the "UDP Multicast" Example project and run the sender from the RT and receive on the HOST?. What changes needed to me made to get this to work?.

 

I cannot get it to work, not even old RT code that used to work. What I mean is RT opens and UDP writes without any errors, but on the Host side, the UDP opens OK, but the read returns Error 56: timeout, never getting any packets.

 

sbRIO-9636 Softwarel.png

 

Seriously, I don't recall have any problems with this in LV 2011,2012...what's changed?.

 

Regards

Jack Hamilton

0 Kudos
Message 7 of 29
(6,063 Views)

 


MrJackHamilton wrote:

 

Now I'm confused. How does one tell from the software tree in Max that the OS is VxWorks or Linux, should I care?.


 

sbRIO 9636 has been always and still is a VXWorks target as can be seen here. While it is theoretically possible that NI might port NI Linux RT to it this is not going to happen as they are using a PPC CPU (the main reason they switched from Pharlap to VxWorks at that time) and porting NI Linux to a new architecture is always a  time consuming process and these targets are already older and are only mainteined but not actively developed further.

Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 29
(6,046 Views)

Rolf,

 

Not to be a wank, but that list is from 2009, this is 6 years ago!. There is no statement of "This will never change". As I am in the process of grasping for what the source of my problems are, a rational person is not going to consider a post from 2009 as relevenat. Especially, since MAX provides an RT version 14.5 (the latest) OS download for the sbRIO-9636 and the cRIO-9073 for that matter.

 

NI has some responsibilty to notify the customer of relevent changes...So I find to odd the Installed software tree does not display if the OS is VxWorks or Linux..(Indicating its not relevant to you)...then Spex in his post hinting that it's 'obvious' that the sbRIO-9636 runs on VxWorks....From a post from 2009?.

 

Again, LabVIEW has always promoted its platform as OS independant. So I'm not over reaching expecting UDP code that works on Win7 to run on VxWorks RT and or Linux.

 

If there is a tweak for a specific OS version, then NI should run the "OSversion.vi" first then make the tweak under the hood!.

 

I know this is frustrating, but maybe is NI would add that one line of code...all this could be avoided. Additionaly, all this information is scatter across multiple forums, LavbVIEW, RT and Chassis specific...If you have a dual ethernet port on a cRIO there are others things you have to do to open a specific interface...not easy to find this information.

 

 

CAPTION: Some Consider This Current Information?

 

RealTime Versions.png

 

 

0 Kudos
Message 9 of 29
(6,026 Views)

Hi Jack,

 

Sorry if I implied that it should be obvious that a specific target is running Linux vs. VxWorks.  Also, the KB that Rolf referenced does indicate that it was updated as recently as August 2015.  I'm asking the ELP engineer/AE who should be monitoring this thread to update the KB to remove the reference to LabVIEW 2009 SP1 as Primary Software Version to avoid the confusing impression that this information is out of date.

 

Screen Shot 2015-09-17 at 12.22.38 PM.png

 

You are correct in assuming that NI's goal is to support LabVIEW functions in such a way that they abstract any unique capabilities of the underlying OS.  In short, it shouldn't matter to the majority of programmers what OS is actually running on the target.  There are situations where NI falls short in this goal, and I believe our role at this time is to determine if this is one of those cases, or if something else is affecting the UDP traffic from your sbRIO-9636 to Windows 7.  

 

NI has emphasized the role of Linux in our latest generation of hardware targets to open up the OS in a way that we know that a large set of Linux 'hackers' can use to their advantage if they are able and willing to work at a lower level. The main goal of my previous post was to get us on the same page solving the same problem, as it wasn't clear to me how Linux (the suspect accused in your original post) played a role in the problem. It is apparent now that Linux doesn't play a role, and the IP Routing tables 'hack' (single line of code referenced) no longer applies either.

 

There was a well discussed and documented issue with UDP Multicast on VxWorks targets prior to LabVIEW 2009. As of LabVIEW 2009, UDP Multicast was explicitly supported on VxWorks targets, so I'm surprised you are having this issue.  As far as getting to a resolution, I don't have much dedicated time at my desk this week with hardware to setup and test this behavior.  My gut feeling is this comes down to a configuration issue, not an OS or LabVIEW limitation, but we need to prove.  

 

In addition to the KB update requested above, I'm asking the AE monitoring this thread to chime in and indicate if they can get a hardware setup (could be any VxWorks cRIO or sbRIO target) to test the UDP Multicast example VI. Specifically, it appears that Jack is using sbRIO-9636, a Windows 7 host, and LabVIEW 2014.5.

 

Regards,

Spex
National Instruments

To the pessimist, the glass is half empty; to the optimist, the glass is half full; to the engineer, the glass is twice as big as it needs to be has a 2x safety factor...
0 Kudos
Message 10 of 29
(6,014 Views)