UDP delay

[PhillipBrooks]

Maybe if we knew more about the FPGA device, we could help.

Is it an NI product?

Is there an OS between the FPGA and network interface?

What IP stack does it use?

I worked on a project years ago that used a custom UDP implimentation that had been ported to VHDL; it was not RFC compliant. It gave me no end of problems from LabVIEW but the linux guys had no problems receiving data.

[Moonself]

The FPGA is a xilinx sp601 and sits on a pcb we designed to talk with a front-end chip.

The protocol implemented to talk with it is described here and is fairly simple.

I do not think the problem is in that, though, because as I said, Labview works fine if I talk over the network rather than on a private lan.

The FPGA responds quickly to commands sent from labview but the data gets stuck somewhere between the ethernet card and my front VI...

[Moonself]

Hi,

I finally managed to solve the issue and nathand was right: the problem was in the "dot notation" used to identify the sender of a packet in the UDP read.

I thought I had removed all the "ip to string" functions in the VI but there was one I had completely forgotten about. I don't even need to identify the sender, so I do not know why I even bothered adding that piece of code.

It was only when I started to analyze the packets being sent that I realized there were still some request of identification going on along the net. At that point I checked all my code again and was able to locate the function causing the problem.

Thanks again for the support.

Paolo

[scottrf]

This suggestion of setting the IP to String dot notation to False helped me out. I was going crazy trying to figuring out a 3.5-4.5 second delay. If I had no receiver active, eveything was ok. If I had a receiver on the same PC, the UDP write function exhibited this delay, even though the IP to String was in a different vi in a receive routine.