UDP delay

[Moonself]

Hi everybody,

I am developing some VIs to talk to an FPGA via ethernet using UDP packets.

The VIs work fine: I can write to the board and read back from it but there is a delay of about 5 second between when the packet is sent from the board to the PC (Windows 7 Enterprise, Labview 2009) and when the labview code actually shows it.

To be more specific, the PC has two ethernet cards: one is connected to the internal network and to internet, while the second one has a fixed IP (192.168.0.100) an is connected directly to FPGA.

If I use the first card the communication is normal, no delay.

If I use the second one, the PC sends the query, the FPGA replyes, but then there are a few seconds before Labview will show me the value (and terminate the exectution of the VI).

Note that if I use a python script to talk to the FPGA using the second card, the communication is fast, so I suspect for some reason Labview is "upset" by the fact that the UPD packets are "non standard". Does anybody have any experience with something similar?

Thanks in advance.

[Moonself]

A little more information:

I am now using a dummy hardware to check the communication: a python script simulates the FPGA and prints on screen the packets being sent and received.

Both PC (the labview one and the dummyhardware one) have two ethernet cards, one connected to the lab main network, the second one connected only through a router and with fixed IP.

The test VI consists in a simple read register query (see attached VI): a writeUDP followed by a readUDP. Obviously the "openUDPsocket" and "closeUDPsocket" operations are performed on a higher level VI, which does only that.

The dummy hardware shows that the write operation is immediately followed by the reply but somehow the UDPRead block waits a couple of seconds before sending the data to "DataOut". This only happens if the communication is performed across the direct link (pc-router-dummyhardwarepc), while if the same VI is run across the lab network, everything goes smoothly.

Also, the delay is not related to the timeout value set in the VI.

Again, any help would be very appreciated.

Paolo

[PhillipBrooks]

UDP Open Function

http://zone.ni.com/reference/en-XX/help/371361H-01/lvcomm/udp_open/

net address specifies on which network address to listen. Specifying an address is useful if you have more than one network card, such as two Ethernet cards, and want to listen only on the card with the specified address. If you do not specify a network address, LabVIEW listens on all network addresses. This function broadcasts only on the default network address. 

Might be of help:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Ability-to-select-interface-for-UDP-writes/idi-p/18392... 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-user-to-select-the-which-NIC-to-use-for-network/...

[Moonself]

Hi Philip,

first of all thanks for the reply.

Unfortunately the documentation you provided did not solve much: indeed, I use the "net address" input of OpenUDP exactly to select which way to communicate with the hardware.

The problem is that if I tell labview to open the UDP socket using one netword card, everything is fine. The other is slow.

Of course I have tried to swap them and it is not a network card problem.

I have also tried to fisically remove one of the cards and use only the remaining one and the result is the same: if I go through the lab network it works fine. If I connect the hardware directly or via a router then the connection has a delay.

I am starting to suspect that what upsets labview is the fact that I manually set the IP address of the card (which I need to do when using direct connection, since there is nothing on the network to assign IP addresses in that case).

Paolo

[nathand · Accepted solution]

Set the "Dot Notation" input of "IP to String" to TRUE.  This is the function that's causing your delay.  When you use the fixed IP address, connected directly to the FPGA, there is no domain name associated with the address, so the lookup waits and eventually times out.  That timeout is the delay you are seeing.  Setting "Dot Notation" to true will skip the domain name lookup and return the IP address as a string.

[Moonself]

Hi nathand,

thanks for taking interest in the problem.

Unfortunately your suggestion did not work.

EDIT: As I said, it looks like the delay happens between the answer being sent and Labview actually acknoledging it.

[nathand]

I still think it's in the domain name resolver, I've seen issues like this before... Can you take out both "IP to String" and "String to IP" and see if it fixes the problem?  You can use a numeric constant in place of the address input to the UDP functions.

[Moonself]

Hi,

see the attachment.

As you can see, in this configuration I use the string to IP to determine which boards are available, then use an "index array" to select the board.

However, following you suggestion, I have tried to:

-type the IP address in a string and convert

-type a number directly into the "net address" input. Specifically, since the IP address is 192.168.0.100 I have used a numeric constant 0xC0A80064

The problem is still there.

I think you are partially right, that is, it looks like Labview struggles to recognize the manually set IP, times out and then uses the one I set. I do not know how to avoid that though.

[nathand]

---

@Moonself wrote:

I think you are partially right, that is, it looks like Labview struggles to recognize the manually set IP, times out and then uses the one I set. I do not know how to avoid that though.

---

I'm not quite sure what you mean by this.  I don't know why it would be specific to LabVIEW, but I wonder if there's a networking configuration issue here.  When you connect directly to the FPGA, are you still connected to your LAN as well on the other ethernet port?  Is it possible your gateway/netmask settings or network card priority order are at fault?  If you swap the ethernet cables (so that the one that was connected to the LAN is now connected to the FPGA, and vice versa) does it make a difference?

I don't think there's anything odd about the way LabVIEW handles UDP packets, the functions are just wrappers around calls to the operating system.

[Moonself]

---

---

I'm not quite sure what you mean by this.  I don't know why it would be specific to LabVIEW, but I wonder if there's a networking configuration issue here.  When you connect directly to the FPGA, are you still connected to your LAN as well on the other ethernet port?  Is it possible your gateway/netmask settings or network card priority order are at fault?  If you swap the ethernet cables (so that the one that was connected to the LAN is now connected to the FPGA, and vice versa) does it make a difference?

I don't think there's anything odd about the way LabVIEW handles UDP packets, the functions are just wrappers around calls to the operating system.

---

The problem is definitely labview*: if I use a python script to send the commands from PC to the FPGA, there is no delay.

Also, I do not think it is a network card priority issue because I have removed all the cards from the PC, leaving just one, and the problem still occurs. It also happens when using a different pc, with XP instead of Win7.

I should also point out that, although I mentioned it looks like a "time out", the UDP packet is not lost: after the mentioned ~5 sec delay, I can see the result of the operation and it is correct (for instance I write to a register and then read it back).

*Or better, the problem must be related to labview+network card setting, since it only happens if I specify the IP address of the card.