Can't send UDP data from cRio to Raspberry Pi

[mako_ruth]

Hi all,

My set up is a PC running LV 2019 with remote target cRio 9038. I've been trying to establish a UDP communication between the cRio and a Raspberry Pi 4 running the Pi OS. I have configured the second ethernet port on the cRio following this guide: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9ULSA0&l=en-CA

All devices communicate through ethernet cables. I have a C++ UDP sender and receiver on the Pi and I could send data from the Pi to cRio and have it displayed on the host PC. However, I couldn't send anything from LV/cRio to the Pi. The UDP code on the Pi should be working properly as it could send and receive data with my personal laptop running python scripts. 

I'm thinking there are issues with either my LV code, cRio config, or host PC config. Any help would be appreciated!

[IlluminatedG]

Without more details, there's nothing explicitly wrong with the LabVIEW code.

Are you able to send UDP communications between 2 C++ applications? What variables have you tried isolating that leads you to LabVIEW as the fault? (Full disclosure: I expect the answer to be "not much" and welcome correction to that assumption elsewise we can suggest additional tests to try). Have you done any captures with Wireshark that can ensure the expected packets and data are being communicated?

Knowing the C++ code/toolkit being used may help. There's less to get wrong on the LabVIEW side so outside of any LabVIEW internal bugs my initial suspicions lay outside of LabVIEW.

[mako_ruth]

Thanks for the response!

Wire shark is a great suggestion as I did not check the actual state of packet communication. I was able to communicate between C++ servers and clients running on the Pi, as well as between the Pi (C++) and a Windows laptop (Python), which led to my conclusion that there might be an issue with LV/cRIO/host PC.

Since the LV code seems to be correct, I will double check with Wireshark to see if any data is actually being sent out from the cRio. I don't have the c++ file on hand but I've attached the example code I referenced. 

[IlluminatedG · Accepted solution]

Yup that's about as basic as it gets and the port byte ordering is being handled correctly at least as far as I know to. Curious to see what the wiresharking shows and what addresses are configured for the cRIO (both ports) and the PI. The cRIO may be sending the packets out on the primary adapter if the Pi address and secondary adapter address don't fall in the same subnet.

I'd also try putting everything on a DHCP network and try with the resulting IP addresses as another test. Is there a reason to keep the PI isolated? (There are a bunch of plausible reasons, do they apply here?)

[mako_ruth]

While I'm figuring out Wireshark and DHCP address, here's the answer to your other questions: both of the cRio ports and the Pi are assigned static IP address on the same subnet. With the primary and secondary ports having different addresses.

What were you referring to when you mentioned "keeping Pi isolated?" I'm not 100% sure. 

Thanks for your help on this, I'm new to LabView and it's appreciated. 

[IlluminatedG]

Having the Pi on an isolated network from the PC. Why use the secondary port on the cRIO for the Pi? Why not everything on a switch on the main NIC? Is that specifically to have static IPs? Plenty of valid reasons, just curious since you'd also need the PC on that network segment to wireshark it from the PC.

[mako_ruth]

Hi, sorry for the late reply!

I've solved the issue finally. What you said in one of the previous replies was the issue: I didn't configure the IP addresses properly. The Pi and the secondary port need to be on the same, separate subnet from the host PC and primary port. Previously I had them as different entities on the same subnet and wasn't working. An example of config can be seen here: https://forums.ni.com/t5/Real-Time-Measurement-and/cRIO-Secondary-Ethernet-Port-Usage/td-p/3370496

Thank you very much for your advice!

[rolfk]

Glad you solved it. As you found out multiple ports in the same subnet on the same device is only an option if you use special software that can bridge them as a single network interface. Sometimes helpful to increase the pipe diameter of the network when you need to push out lots of parallel streams.

Another issue I recently found: Both ports were correctly configured as separate subnets but both had also a gateway configured. All kind of weird errors occurred as the cRIO could apparently not decide which of the gateways to use and tended to use the one from the second port most of the time, which was a private network without all the IT infrastructure. I hadn't noticed that extra configuration on the second port and also assumed that it would by default always pick the configuration from the first port eth0 anyways. But not so!

[mako_ruth]

That's an interesting issue you've outlined! I did not configure the gateway for my cRio second port or Pi and luckily didn't run into that issue, hopefully it helps someone in the future!