LabVIEW
UDP responses from multiple PCs
Solved!
- On the first UDP open, you need to wire the receiver port, not the remote port! (That's the source port for outgoing packets that later will receive the replies.)
- I agree with mike that you should just send to 255.255.255.255.
- Don't open a second session, keep the original connection ID open
- Receive in a loop until all replies are received (e.g. until there is no new data for a certain while). You can collect all responding addresses from the lower terminal.
- Only close the session at the end.
See how far you get. I cannot test of course.
I assume that the "little boxes" send unicast back to your program.
No way for me to test, but try something like the following:
notes:
- I "simplified" the calculation of the local broadcast address. No need to jump through flaming hoops! 😉
- You should only add received data to the output array if there is no error. Not implemented here.
- etc...
@altenbach wrote:
No way for me to test, but try something like the following:
notes:
- I "simplified" the calculation of the local broadcast address. No need to jump through flaming hoops! 😉
- You should only add received data to the output array if there is no error. Not implemented here.
- etc...
The LabVIEW documentation isn't clear to me.
There is no input specifically called "local broadcast address".
Could you explain whey the IPv4 address is being OR'd with the negate of the subnet mask?
I am clueless as to the purpose.
@nyc_(is_out_of_here) wrote:
There is no input specifically called "local broadcast address".
With "local broadcast address" I meant the "broadcast address for the local subnet".
You are always sending from your own address. That's your own unicast IP address which is automatically added to the header of all outgoing packets. The devices at the other end will respond to the broadcast with a unicast to the source IP of the received packet, i.e. your adapter. Same for the port. "open UDP" reserves a local port, which is used as source port for the outging packets. The destination port is whatever the other devices are listening at, so you have no choice.
All adapters receive messages to their assigned IP address, to the local subnet broadcast address, to the generic broadcast address (255.255.255.255) as well as to certain multicast addresses. On the local subnet, things are actually guided by the MAC address and each adapter maintains an ARP table to correctly form the ethernet header. Your local switches will know (from learning) all connnected MAC addresses and their assigned IPs and will send out any incoming packet to the right connecter. They recognize broadcasts and will automatically send them out on all other connectors. If the address is not local, the ethernet packet is set to the MAC address of the router (the default gateway) and it will read the destination IP to determine which interface (i.e. other subnet) the packet should go out, etc.
@nyc_(is_out_of_here) wrote:
Could you explain whey the IPv4 address is being OR'd with the negate of the subnet mask?
I am clueless as to the purpose.
Well, that's the correct math, look it up! (the original code does exactly the same, but in a Rube Goldberg kind of way ;))
For example if your IP address is:
- 192.168.5.45 and the netmask is 255.255.255.0, the broadcast address is 192.168.5.255
- 10.47.5.45 and the netmask is 255.0.0.0, the broadcast address is 10.255.255.255
- etc.
Thus the local subnet broadcast addrees can be determined from the IP address and netmask.
Note that each address is internally just a U32 integer and boolean operations will function bitwise.
nyc wrote:If 255.255.255.255 does not work, I am not clear how to target one instrument vs the other.
The current VI works but only shows the information for one instrument.
I need the ability to receive the response from both and possibly more in the future.
I have no clue what IP addresses I need to wire to which inputs on the UDP VIs.
Did you try my code? Do exactly as I show in my image. How far did you get?
Your code is only reading one incoming message and then closes the connection, so how do you think you should receive more than one? All other incoming packets are lost forever. You also open a new connection after the original connection is closed. This takes time so it is possible that some of the devices responds before you are even listening yet. You need to do all with the same connection ID as I show.
If you want to target one specific instrument, you need to do it via its unicast IP address.You get those once the broadcast works correctly and you can parse all the replies. (There will probably some info in the packet payload, but the actual remote IP can be obtained from the UDP read as I already showed. Make sure to enlarge the cluster array indicator to see all returns.
