UDP no longer working

[jbuckmaster]

I've had to upgrade from LV 8.5.1 to LV 8.6.1 because of new hardware (a 9112) on my cRIO.  After the upgrade, my UDP streams no longer work.  I get an 'Error 54' on both sides (client and server).  I've double checked the IP settings... no luck.  Can anyone help?

Odd note:  when I 'probe' on the Connection ID output of the UDP Open vi, the debug window comes up labeled 'Port'.  Indicative of the issue?

Thanks in advance...

[Robbob]

Random question, but are you going across subnets with this? I remember seeing an issue with this. UDP is only supported on some routers across subnets, and the error handling of this might have changed.

[jbuckmaster]

To check this, I connected my laptop (also now with LV8.6.1) directly to the cRIO with a crossover cable, eliminating any router.  No Luck!

I'm trying to work around the issue by using the LV8.5.1 UDP vi's  instead of 8.6's...  having trouble finding them!

[jbuckmaster]

Progress?  I disconnected the 'net address' input to the UDP Open, and I no longer get an error.  I don't get and data yet, but this feels like progress... 

[jbuckmaster · Accepted solution]

Yahoo!  <<SOLVED>>  After double checking my configuration, and sending things to the correct adresses...  indeed disconnecting the 'net address' on the UDP Open removed the error and I am now streaming as I was in LV 8.5.1.

Why would such a thing cripple my system?   Why would there be this change between LV 8.5.1 and LV 8.6.1?  I have no idea.  However, this problem that has paralyzed my development since I upgraded is now finally free to progress!

[Bill_in_Detroit]

Mark:

If I may add my 2 bits in to this conversation, I was experiencing a similar problem with implementing UDP read on a RT target that has multiple ethernet ports.  I wanted to be able to "target" one of the processes for communication and thought I could have it "listen" on a specific ethernet port for UDP commands.  However, apparently due to the way that MAX selects one of the physical ethernet devices as "primary" the only way any of my processes running on the RT target could "hear" the UDP messages I was sending was to delete the connection to the "net address" on the UDP Open like you did.  This does not seem to be a logical answer but it works, so to those others of you scratching your head or pulling out your hair over a failure of a RT process to "hear" your UDP transmissions from an external host, try leaving the "net address" connection open and sending the UDP messages from your external host to the primary ethernet device and the port you have chosen.  It works for me, too!

BTW, I am able to stream from any of the UDP ports and ethernet devices on my RT target to my external targets with no problem.

Bill_in_Detroit

[robdevyogi]

I had the same issue. I upgraded from RIO 2.4.0 (LV 8.5.1) to 3.4.0 (LV2009SP1) and UDP Open started returning Error 54.  Initially I was able to get it working again by avoiding use of shared variables in the VI (used globals and then put the shared vars in different VI), but didn't work when I ran the top level VI (which has shared vars). But I finally got it remedied by following this solution.  I presumed the IP address input was required for the UDP Open, but that's not so!

Thanks, this was very helpful!

(Apparently there is a CAR for this issue: CAR 23544)