UDP Multicast on cRIO can write messages, but not read

[ng1902]

Hello,

I'm having some trouble with UDP multicast communication between PC and cRIO. I'm able to broadcast UDP messages from the cRIO to my PC, but messages sent from the PC don't make it to the cRIO.

Some backround on what I'm trying to do:

Spoiler

I'm making a simple process manager to use in several headless applications. The idea is that the headless applications have a process running which broadcasts it's status (along with a Unique ID so I can tell which process is which), and all processes would broadcast on the same address. The Process Manager will listen to the broadcast port and create a list of all of the current running processes. This part is working.

There are some buttons on the Process Manager to control processes (currently just a stop command). When you select a Process and click Stop, it broadcasts a UDP message along with the Unique ID of the process you want to stop. All of the processes receive the message, but only the process that has a UID match handles the message.

The Process Manager is able to receive commands from all processes running on my PC and the cRIO, but is only able to send messages to processes running on the PC. Messages sent from the PC to the cRIO are never received.

I've found a Knowledge Article about UDP Multicast Failing on RIO and followed the solution, but it didn't help. I've seen a few posts on the forums too, but most were about not being able to write from cRIO to PC. 

I'm running LabVIEW 2018, on Windows 10. I have the cRIO IP address set to 192.168.127.89, and my network adapter set to 192.168.127.88.

I've attached a modified version of the UDP Multicast example I've been using to try to get the messaging going.

Has anyone had similar issues with getting cRIOs to read UDP Multicast messages? Any suggestions on how to get this working?

[Petru_Tarabuta]

Hi ng1902,

1. Did you try setting the cRIO to DHCP, instead of static IP? Are the UDP messages still not received when cRIO is DHCP?

2. Did you create two simple VIs that are dedicated to replicating this issue? I.e. a VI on the PC to send a UDP message, e.g. "Hello World", and a VI on the cRIO waiting for this message. This is to remove any complexity in the Process Manager that might hide the problem.

3. Does the cRIO receive TCP messages sent by the PC? Can the cRIO and PC achieve bidirectional comms using Network Streams? In other words, does the issue only happen with UDP, not TCP or Network Streams?

Regards,

Petru

[ng1902]

1. I just tried DHCP and Link Local, UDP messages weren't received by the cRIO in either case. However, the PC was still able receive messages from the cRIO.
2. Yep, I attached them as a zip in the previous message. I just realized everyone might not have LV2018, so I attached a zip with it saved as LV2017, 2016, 2015, and 2014.
3. I've tested TCP, and Network Steams, and Simple UDP (ie: not Multicast), and all work. The issue seems to only be with UDP Multicast.

[ng1902 · Accepted solution]

I've come up with a solution!

Instead of the having the Process Manager use UPD multicast to send commands to every single process and having the process ignore commands meant for a different process, commands are now sent using the regular UPD protocol.

When a Status message is received, the IP Address of the sender is stored alongside it's UID and status. Then, when a process is selected and a command sent to it, the IP Address is fed into UDP Write and sent directly to that process. I think makes a lot more sense than broadcasting commands over multicast, since I only want one process to handle that command anyways.

This works wonderfully, since a single UDP connection can write to many different addresses. I was avoiding TCP & Network Streams because I didn't want to have to deal with some sort of connection manager and thought UDP Multicast was the only way to go, but regular UDP saves the day!

I've attached updated examples with the status sent over Multicast and commands sent with standard UDP, in case anyone finds it useful in the future.

[Petru_Tarabuta]

Happy to see that you solved it.

Indeed, regular UDP sounds like a good choice for the PC-to-cRIO commands.

1. Does the PC ever need to issue the same command to two or more cRIOs (not necessarily all cRIOs) at the same time? Does this happen so rarely that using a for loop to issue the command to each cRIO is feasible?

2. Do the cRIOs need to report their status to the PC only, or also to the other cRIOs? If only to the PC, is there a need for the "Read-only" multicast socket on the PC? Could multicast be removed altogether?

3. The Knowledge Article you mentioned in the initial post is a great resource. The article states that the issue happens only when the IP of the cRIO is static. However, your testing shows that the issue also happens when the cRIO is in DHCP and Link-local configuration. Could the Knowledge Base article be incomplete/slightly incorrect?

[ng1902]

1. I added a ping command which will be sent to all processes (whether they're on PC or cRIO), so that we can tell if anything has hanged. The command that gets sent turns on/off pinging and sets the polling frequency, and that gets sent in a for loop to all running processes. I can't think of any messages that will need to be sent to everything at a high rate, sending infrequent commands in a For loop should work well.
2. The status will only be read by PCs, but potentially on several PCs at once. There are a few developers on the team, and they will all want to be able to see the statuses of the various processes we're working on. Having the status sent over multicast means we don't need to worry about what computer the Process Monitor is run on, and anyone can run the Process Monitor at the same time.
3. I wonder if that KnowledgeBase is incomplete... I manually added the rule, and used WinSCP to add those two rules to the ifplugd.* files, but it didn't allow the cRIOs to receive multicast UDP messages.

[nestorl]

Thanks for pointing that out! I've flagged that KnowledgeBase article to be updated. We appreciate you bringing this to our attention!

[Ghost_coder]

Is there an update on this?  I have the same issue, TCP works, but UDP multicast seems blocked.  Same vi works on windows, but udp read timesout on cRio.  Seeing multicast packets on another computer on the same network switch using wireshark.