UDP Unicast did not seem to work on Linux RT cRIO-9036

[syang]

Hi folks,

I am running LabVIEW 2014 SP1 on Windows 7 laptop with cRIO-9036 which has Linux RT on it. During upgrade of my LabVIEW 2011 products, I found that the UDP unicast appeared to be broken.

This is what I did:

I opened the NI's "Simple UDP" example, then ran the sender on RT in dev environment and receiver on the PC. There was no data coming through. Probing RT returned no error either.

However, I ran the "UDP Multicast" example and everything worked.

Can someone confirm this issue or did I missing something?

Thanks.

Tony

[Nick-C]

Tony,

When you moved the Simple UDP - Sender.vi to the RT target in the LabVIEW project, did you change the remote address constant on the block diagram from "localhost" to the actual IP address of the host computer?

[syang]

Hi Nick,

I guess I did not make the question clear yesterday and now I have more information to share today after working with NI support and one of my elder colleagues. Essentially in our RT code, we programmed RT to do unicast to IP "FFFFFFFFF" (i.e. 255.255.255.255) and this did work in both 2011 and 2014 VxWorks based controllers (i.e. 9014 and 9025).

However, I am not able to do this anymore on Linux RT in 2014SP1. I would get a run time error 59: "The network is down, unreachable, or has been reset."

Back to your question, yes, that example did work if I entered my host IP.

I believe we had issues doing multi-cast on VxWorks-RTs in the past, but unicast of FFFFFFFF worked for us. Now on Linux RT, unicast to FFFFFFFF is forbidded. Can you confirm if this is a LinuxRT-specific issue? And if so, why and what are the solutions?

Thanks.

Regards,

Tony

[BlueCheese]

255.255.255.255 is a broadcast address, not unicast. This requires the underlying socket to have the SO_BROADCAST option set. I don't know if LV sets this on sockets it creates...

[syang]

Interesting information, I did not know that; although I did have strong suspicion of using 255.255.255.255. Nevertheless, this works on VxWorks based RT but not Linux RT. I will get more information from other senior colleagues to see why it was a unicast to FFFFFFFF.

Thanks for your input.