Error 54 on udp multicast cRIO

[danbrown]

I'm trying to get a cRIO-9075 broadcasting data over a network with UDP. I've opened the UDP multicast examples and they work fine when I run them on my development computer. When I deploy and run the examples on the cRIO controller however, I get either 'Error 54 - the network address is ill-formed' if trying to use the send/recieve example or run UDP open in read/write mode, or "Error 59 - the network is down, unreachable or has been reset" if i try to use just UDP send or UDP open in write only mode.

I'm using a valid multicast IP address that is within the multicast region (234.5.6.7 as in the example), have tried multiple ports, (0, 58432, 50001...) and have tried with my firewalls disabled, wireless internet connection and bluetooth all disabled. The cRIO is connected directly to the development PC via a straight network cable, although I'm pretty sure my network card is sorting out the crossover detection as everything else on the connection is working fine.

Does anyone have any ideas on how to debug this? I've kinda hit a brick wall here, so any help would be greatly appreciated.

[AH-NI · Accepted solution]

Hi Dan,

I have a number of steps you can try:

1) Would you be able to reformat the cRIO, then reinstall the software from MAX?

2) Try setting the IP to Static, and choosing an IP. 

3) Then try setting the default Gateway to the Computers IP address. 

I look forward to hearing from you,

[danbrown]

Hi Aidan, thanks for your help.

I tried setting the IP address to static and set the gateway to the PC's IP address and no longer get Error 54. So good news! I also tried this with an IP address on the same subnet used by my router and was able to connect, deploy and run the UDP multicast example without errors over my wireless network. Using the UDP Send/Receive example shows no errors on sending and the sent data is also received and displayed as expected.

Unfortunately however, that's where the good news ends - I've tried running the UDP Receive vi on the development PC but data sent by the cRIO isn't picked up. The problem doesn't seem to be limited to the cRIO either; running the Send and Receive example pair both on the development machine gives the same result - no errors are returned, but data isn't passed between the two vi's. Incidentally using the TCP/IP communicators over the same port works fine.

I'm a little confused as to what's going on here - why did setting the IP as static and the default gateway work? What does the error 'address ill-formed' really mean, in this context (given that the address was, as far as I can tell, a valid one)? And of course why is data being 'recieved' by the Send/Receive vi, but not passing to the other Receive vi, even though they're both on the same machine, listening to the same port?

[AH-NI]

Hi Dan,

Apologies for the late delay - I have been on annual leave recently.

I wanted to clarify some things with you:

1) When you don't change to a static IP address as previously suggested you get the following errors:
Error 59 when running UDP WRITE ? (running UDP Multicast Sender example)
Error 54 when Running UDP Receive ? (running UDP Multicast Receiver example)

2) When you do have a static IP:

-The cRIO is able to Recieve data successfully sent by the development computer: cRIO Running Receive vi, Dev Computer Running Write.

- The cRIO is not able to successfully send data to the development computer: cRIO running Write, Dev computer running Receive.

3) Are you able to upload printscreens of the errors?

4) Can you confirm which port you are sending the data through?

5) Can you provide me with your computer specifications, including the OS & network card?

Kind Regards,

[danbrown]

Hi Aidan,

What you said was correct, however it seems that after trying again this time I've had success transferring data. I'd doubt my code, and will be sure to post snippets next time, but as my post says I ran the labview UDP multicast example pair on the development machine, so I can only suppose a network hitch... Very strange, as sending data over the same socket with the TCP/IP example worked.

Since then things seem to be going mostly smoothly - I've been able to broadcast data from the cRIO and pick it up on the development PC. I have hit a bit of a hitch with sending datagrams of 8192 bytes ...

Spoiler

I'm getting 'error 113 - the datagram is too large for the buffer or other network limit' on the UDP recieve end. I believe 8192B is the maximum UDP packet size, and don't get any errors on write, but even increasing the socket buffer size by modifying the windows dll as per here (http://digital.ni.com/public.nsf/allkb/D5AC7E8AE545322D8625730100604F2D) I'm still receiving the error. Using smaller packet sizes (e.g 540B) seems to work, but as I'm trying to maximise throughput it could pose an additional limitation. I've read 64MB is the UDP protocol maximum size, and 8192B is a labview limitation. Any ideas on this?

...but I suppose that's another issue.

For now I think I'll leave the cRIO on a static IP and not get hung up on this issue. Thanks for working through this with me Aidan.

For the record: the port was 58432, multicast address 234.5.6.7 as in the UDP multicast examples. development PC was XP, 2.26GHz dual core w/ 3GB RAM (limited as 32-bit), will update with ethernet card later as I'm on a different machine right now.

[AH-NI]

Hi Dan,

I'm pleased to hear things are now going more smoothly.

In terms of packet size, the link below provides a recommended Maximum (4KB).

http://digital.ni.com/public.nsf/allkb/7A19D1B78711A8A886256E92004F7D4D?OpenDocument

Kind Regards,

[danbrown]

Hi Dan,

4KB works nicely, although I've noticed this evening that using 8192B also works fine - it seems what works and what doesn't depends on the weather! Still, if 4096 optimises throughput then I'll go with it unless I have reason to otherwise - so far I haven't been able to properly benchmark performance, but I'd have expected larger packets to incur less overhead so be faster. I'd also think fewer write loops would put less stress on the CPU, which seems to be my next hurdle.

Still, I'm hitting up against 4-channel 80us sample rate, which isn't too shabby! If i can push a few times 16kHz that'd be even better, since I'm sampling a PWM with signal 16kHz switching frequency, but we'll have to see whether that's possible.

To finish off my last post; ethernet card is a Marvell Yukon 88E8055 PCI-E Gigabit Ethernet controller.