LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UDP responses from multiple PCs

Solved!
Go to solution

My laptop is on a local area network that consists of the laptop, a switch, and two RF switch boxes.

Not connected to the corporate network.

 

According to the equpment vendor a command can be broadcast to the local network using UDP and all tthe boxes that receive the request will respond.

 

The VI that they gave me only shows the response for one the boxes at a time. 

 

How do I go about modifying the VI so that the response from both boxes are received?

 

Attached is their VI which I have simplified. The IPv4 address is for my laptop.

The boxes are at 192.168.0.141 and 192.,168.0.142

 

 

 

 

0 Kudos
Message 1 of 14
(5,434 Views)

Well, the IP address coming out matches the definition of Broadcasting address. So the math part looks OK.

https://en.wikipedia.org/wiki/Broadcast_address

 

I would try the following

  • Target IP address 255.255.255.255 (local broadcast) (note: without the bitwise OR)
  • Target one instruments IP and see if it responds.
  • Get wireshark and see if the packets are coming in (and ports match)

Edit: I apologize, I MAY have missed the original intent. Are you asking for advice on how to structure the VI to receive both, or just how to get the instruments to respond?

Josh
Software is never really finished, it's just an acceptable level of broken
Message 2 of 14
(5,403 Views)

See ImageUDP

0 Kudos
Message 3 of 14
(5,357 Views)
  • 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.

0 Kudos
Message 4 of 14
(5,344 Views)
Solution
Accepted by topic author nyc_(is_out_of_here)

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...
Message 5 of 14
(5,334 Views)

@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.

 

 

0 Kudos
Message 6 of 14
(5,296 Views)

@JW-JnJ wrote:

Well, the IP address coming out matches the definition of Broadcasting address. So the math part looks OK.

https://en.wikipedia.org/wiki/Broadcast_address

 

I would try the following

  • Target IP address 255.255.255.255 (local broadcast) (note: without the bitwise OR)
  • Target one instruments IP and see if it responds.
  • Get wireshark and see if the packets are coming in (and ports match)

Edit: I apologize, I MAY have missed the original intent. Are you asking for advice on how to structure the VI to receive both, or just how to get the instruments to respond?


I am at home now.

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.

0 Kudos
Message 7 of 14
(5,290 Views)

@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.

 

 

 

0 Kudos
Message 8 of 14
(5,243 Views)

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.

0 Kudos
Message 9 of 14
(5,239 Views)

@altenbach wrote:

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?

 

 


I just tried your VI. Thank you.

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.

 

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?

 

 

0 Kudos
Message 10 of 14
(5,189 Views)