LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Send and receive on same UDP port

I need to be able to send and receive data on the same UDP port.

I wrote a simple UDP sender, and a simple UDP receiver (based on the example VIs in NI Example Finder "UDP Receiver.vi" and "UDP Sender.vi".

Run separately, they both do as I intended: The sender sends out a message at a rate of 1Hz, while the receiver sits there attempting to read until something turns up.

When I tried combining them into the same VI I ran into difficulties. If there is data arriving on the port then everything works fine. If, however, there is no data arriving, then the UDP read returns an error of 66 "Port closed by peer".

Can anyone shed any light on this? I am trying to send out my messages at 1Hz (they are heartbeat messages), whilst maintaining a receive loop that is waiting for incoming heartbeat messages to begin. What is going wrong??

My test file is attached if it is of any use...
0 Kudos
Message 1 of 5
(6,999 Views)
Could you tell us a little bit more about the program that runs on the other end of the networking gear? Is it also LabVIEW code?

"Closed by peer" most likely means that the other side stopped listening on that particular port (e.g. because the server is no longer running). This would also explain why no packets are coming back. The OS thus responds to the UDP packet with a ICMP(3,3) packet, informing your program about this fact.

My guess is that the problem is remote and not local.
0 Kudos
Message 2 of 5
(6,993 Views)
The program that runs on the other end of the network is a an executable written in C++, running on Linux, that does a very similar thing, but in reverse.

The c++ will do the following: start sending out heartbeat messages on UDP, with a destination port of 31003.

It sets off a receiver thread which does the following:
* polls its local socket (31006)
* sets a flag "x" when there's something to read
* When "x" is set the message is read, and identified as as a heartbeat, and sets global flag "y"

Meanwhile the main execution sits and waits for "y" to be set. When this happens it starts sending out heartbeats... which is what my labview code is waiting for on the other end of the network.

I hope I'm not making this sound more complicated than it should be - each side needs to send and receive heartbeat messages over UDP, but if the other side hasn't started yet, then it seems wrong for the Labview side to crash out. The C++ side seems quite happy to sit there waiting for a message to arrive, waiting on the receive UDP in one thread, whilst sending UDP on the other.

By the way, at the moment the network gear is simply a crossover cable connecting the two machines.
0 Kudos
Message 3 of 5
(6,985 Views)
UDP is connectionless, so you should be able to ignore that error. Have you tried to simply remove the stop-on-error in your receive loop? (I think you can also remove the "OR" and the local variable inside the upper loop).
0 Kudos
Message 4 of 5
(6,980 Views)
Many thanks, that's solved my problem nicely!
0 Kudos
Message 5 of 5
(6,975 Views)