LabVIEW 10, cRIO-9025 and Multicast - Example of Working VI

[MrJackHamilton]

I am uploading a working, tested UDP Mulitcast routine for the cRIO which is tested on two chassis 9039, 9025 in LabVIEW 2017 SP1.

There are some sublties to doing this - especially if the chassis has 2 ethernet ports. Additionally, the VI has code to query and return the cRIO Chassis information and Ehternet port configuration -as the old cRIO Configuration toolkit no longer works.

My heart goes out to those who have banged their heads on this...this was all flawless on VxWorks and now is very spotty on the Linux RT. IMO

Regards and enjoy

Jack Hamilton

[MarkCG]

Hi Jack, I am looking at using UDP multicast on cRIO linux RT. When you say it's sotty do you mean it's harder to get working but that it works ok after that?

[MrJackHamilton]

The spotty part is which cRIO system supports MCast UDP and which do not. Even NI does not know...

Other than that - it's rock solid. 

ALSO!: I my example, you have to change the IP address I hardcoded to your actual cRIO address to get it to work. [Upper left corner of the diagram]

I've done a lot of cRIO stuff...and am happy to help...!

[MarkCG]

ah, that's good to know. Could be a scary thing if you have a deployed system, then for some reason you have to upgrade or swap out a compactRIO for a different model and nothing works anymore.

[MrJackHamilton]

Also, Stay away from the Shared Variable in the cRIO, it can be a problem. We've had a cRIO fail to boot because a shared variable problem - or at least that's what we determined. The embedded should always run - not matter what is happening in the outside world. 

However, it appears there is something in the way the library deploys on startup on the embedded that can cause the problem. There likely was a legitimate cause - perhaps the SV engine on the PC was not running or in an error state...but the cRIO should have completed its boot-up.

We stripped all the SV code out...and it works fine. 

[MarkCG]

I've been using DCAF framework. Learning curve can be steep, especially for creating new modules but it works great and very reliable. No Shared Variables used in it at all, I highly recommend it. 

[csduffey]

Lots of good input on this topic, I'll add one more definitive item that we discovered - it appears that the VxWorks kernels installed in the cRIOs do NOT support IGMP V3 - This was the original issue for us, characterized by the system initially joining the multicast group but 3 minutes later being pruned from the routing tables (PIM Sparse-mode configuration)  Rolling back to IGMP-V2 solved that problem or by forcing the router to do join the group on that port with a hard route

[MrJackHamilton]

Cs,

Thanks for the input. I do recall years ago NOT getting MCast UDP to work on a sbRIO, using code that worked on the cRIO...It took NI support quite awhile to find out that they had not fully deployed the TCP/IP Stack on that particular/series of sbRIO.

It seems [at that time] that the NI Embedded Software Manager decides what's deployed and what's not. The sbRIO/cRIO Product [hardware] Manager may not be aware of the minutia of the actual implementation.

As I've been using LV for decades, I use my own TCP/IP based embedded interface code, employing the LabVIEW TCP/IP primitives and don't use the 'toolkits' (they did not exist when I started!).

That said, the TCP/IP Stack implementation in the cRIO/sBRIO is rock solid and its stood up to lots of scrutiny [Wireshark] and "accusations" from 'C' based programmers over numerous projects over the years. Once it's working - it's working!.