UDP responses from multiple PCs

[crossrulz]

---

nyc wrote:

Also, I am getting one extra blank UDP Read which is the result of the timeout. Is this normal? I would then have to remove strip?

---

Or use the Conditional Indexing tunnel so that you do not add the element in the case of an error (timeout).

[JW-JnJ]

---

@nyc_(is_out_of_here) wrote:

Can you explain why it isn't necessary to do a UDP Open for the UDP Write (port 4950) ?

Also, I am getting one extra blank UDP Read which is the result of the timeout. Is this normal? I would then have to remove strip?

---

That's a long explaination.. but I'm in the mood to try

Spoiler

A port is a way for multiple pieces of software to be listening on the same IP address. As such, each UDP packet contains two pairs of IP and Port. One is the source IP/Port and one is the destination IP/Port.

So, as an example, if your computer is at 192.169.1.100 and the instrument is at 192.168.1.102. You would open a connection and specify a port for that connection, lets say 4951. Your computer now knows that all packets arriving at 192.168.1.100 port 4951 should go to your software. Now you want to send to your instrument. You know your instrument is listening on port 4950, so you send to 192.168.1.120 on port 4950. The packet that gets sent has all of this information:

• Source IP- 192.168.1.100
• Source Port- 4951
• Destination IP- 192.160.1.102
• Destination Port- 4950
  Your data

Now, when your instrument receives that, it can easily see where it came from. Because of this, it knows both the network address your on AND the port your software is listening on. This is why you need to open with one port and leave it that way.

Yes, it's normal. When the UDP read times out, it returns a blank string. You'll also see this for any error in that function. Use Crossrulz's suggestion of the conditional terminal.

[altenbach]

---

@nyc_(is_out_of_here) wrote:
Also, I am getting one extra blank UDP Read which is the result of the timeout. Is this normal? I would then have to remove strip?

---

To be fair, I warned you about that in the original post

QUOTE:

• You should only add received data to the output array if there is no error. Not implemented here.

So yes, where there is an error (the last timeout!) you should discard that. You could e.g. use a reshape array wired to [i] to strip the last element from the output array after the while loop.

---

nyc wrote:

The only modification I had to make to it was to not wire the error cluster to UDP Close. Otherwise, I get a LabVIEW error pop-up about Error 56 on the UDP Read timing out.

---

I think it would be sufficient to just wire the error output of UDP close to "something" (e.g. an error indicator) to avoid automatic error handling popups.  Or you could wire it to a "clear error"  (... or use some of the other suggestions).

---

nyc wrote:

Can you explain why it isn't necessary to do a UDP Open for the UDP Write (port 4950) ?

---

In principle it is often not necessary, because if you leave it unwired, the OS will pick a free ephemeral port (as "source port for outgoing packets" =.the "destination port later used by the devices for replies"). However, it is possible that your devices reply to a specific port, so this might need to be hardwired. This is the port your program listens for return packets, i.e. the server port.

If I would write the device responder code (whatever is listeing on your remote devices), I would return the reply to the originating IP and to the originating source port of the packets, irrespective of what the source port number actually was. Note that all this information is available from UDP read.  This makes it more flexible, e.g. in cases where your local port wired to UDP open is already used by some other program and thus unavailable. You can try to wire a port=0 to UDP open and see if you still see replies. No guarantees!

(NAT often edits source ports and devices expecting specific source ports would need a special alg (implemented on the router) for NAT traversal, etc. Fortunately, all your communications are local so this is not an issue)

[altenbach]

For some further suggestions, try to avoide the IP/subnet calcualtion and use 255.255.255.255 as the destination IP in UDP write. This will avoid problems e.g. if these fields are incorrectly entered.

Also, if 255.255.255.255 does not work, the IP address for "String to IP" can be left unwired and it will automatically determine the local IP address. Of course some computers have multiple IP addresses. (e.g. my PC runs also "virtulabox" thus has some other IP addresses). To get them all, you can right-click "string to IP" and select "multiple output" while leaving the input unwired.