Reading a UDP Broadcast

[CharlesD3]

The broadcast that I am still unable to read is sent from 192.168.168.18 port 1460 to 255.255.255.255 port 13000.  That is a built in feature of the device and I have no control over it.  It is sent every 10 seconds.  I have tried setting the time out on the 'read' function to something just over 10 seconds; leaving it at 25 seconds, and setting it to a short timeout in a loop that lasts more than 10 seconds.  None of those things worked.

If that message goes out and is just vaporized instantly then I am unsure how it is possible to be received.  

[altenbach]

---

@CharlesD3 wrote:

The broadcast that I am still unable to read is sent from 192.168.168.18 port 1460 to 255.255.255.255 port 13000.  .  

---

Can you show us your final code for that? Make sure to not wire 255.255.255.255 to the local IP when opening the connection. The timeout should not matter and the loop wait also does not matter, because the loop rate will be fully determined by the arrival of the broadcast messages. If the read times out, you simply need to clear the timeout error (assuming the error wire is in a shift register)

[CharlesD3]

There really is no 'final' version of this VI.  It's just a UDP open - UDP read - UDP close.  It's a simple matter to just change it as necessary to try anything different.

I am opening the connection on my PC ip address.  I have alternatively left that connection open; as it should then look at the specified port on all networks.

I am opening PORT 13000; and wiring the connection ID to the UDP READ function.  The only error I get is '56', timeout.  If i am using a loop and a shorter timeout, then I use the clear error function before the shift register.

There just aren't that many options to change.  If I try to open the wrong port or the wrong IP, i get an error from that VI.

[CharlesD3 · Accepted solution]

So in case anyone is still following this thread, or if someone else has the same problem and ends up here, I finally and mostly by accident stumbled upon the solution to reading the broadcast.  After opening the destination port (on the correct network), I have to send an empty message to IP 255.255.255.255, on any convenient and available port (1500 is shown in this snippet).  Then I can receive the data I am looking for that was broadcast to 255.255.255.255.  Somehow or another, the empty 'write' command provides whatever information the 'read' command did not seem to be getting on its own.  The timeout on the read command is set to be larger than the interval between broadcasts.  I have used this same structure in a loop with a shorter timeout and it works that way as well; so long as all other criteria are set up 'properly'.