This widget could not be displayed.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UDP read timing out

Solved!
Go to solution

I have the attached VI in question without SubVIs which I'm assuming are inconsequential for now. The VI is running compiled on a machine with wireshark to sniff the packets. I seem to be sending to the destination and it is responding and reaching wireshark (starting at line 64 in the pcap). However, it always times out at UDP Read and I see the error on the output.

 

This is the IP information cluster input into the VI.

 

 

What I've tried so far.

1) Turn off Windows Firewall

2) toggle wireshark promiscuous mode (saw packets both ways)

3) Uncheck checksum offload (had some problems with checksums on sending)

4) Tried 5 seconds timeout and default. No change. All packets are send within 0.2sec

5) Checked the input buffer which is well above the packets being sent.

 

 

Thanks in advance. I'm waiting for a "DOH"... I'm unable to see the Project for the VIs.

Josh
Software is never really finished, it's just an acceptable level of broken
Download All
0 Kudos
Message 1 of 29
(5,561 Views)

You've wired a 5ms timeout to that UDP read.  Maybe you meant 5000 ms?

-Barrett
CLD
0 Kudos
Message 2 of 29
(5,554 Views)

You know, I realized that moments ago. Yes, it should be 5000.

 

However, I also tried the code with the default wait (25 seconds). Same result.

Josh
Software is never really finished, it's just an acceptable level of broken
0 Kudos
Message 3 of 29
(5,549 Views)

What if you ignore error 56 and exit the read loop based on your own timeout?

-Barrett
CLD
0 Kudos
Message 4 of 29
(5,538 Views)

Does it make any difference if you leave the "net address" input of UDP Open unwired?

Also, if you're on Windows, you might try not wiring the "max size" input to UDP Read, since the help notes that wiring any value other than the default can cause an error.

Other than that I'd confirm that all the port numbers are correct - I don't have anything capable of reading your pcap log in order to look at it.

0 Kudos
Message 5 of 29
(5,529 Views)

Unfortunately, I need the net address to specify the card I'm using. This computer has 6 ports. 4 will be used for GigE Vision, and 1 is this custom interface.

 

The packets that are being sent are 1070 bytes in length. I was under the impression that I needed to change the max size to receive these packets.

 

I'll check the ports again.

 

Thanks for the attempts, I'll take any ideas since I've been troubleshooting this all day so far.

Josh
Software is never really finished, it's just an acceptable level of broken
0 Kudos
Message 6 of 29
(5,526 Views)

Update:

 

I created a program to send UDP packets between two ethernet ports on the same computer. I used the same UDP ports. It worked (results attached).

 

So I can send/receive packets on that computer in LabVIEW, but not from the unit. This makes me thing that somewhere within Windows/LabVIEW the packets are being deemed unworthy and dropped. The only differences I can see are that

1) Indentification doesn't increment like LabVIEW does

2) The unit sends packets that have the "do not fragment flag"

3) The UDP checksum (not the IP checksum) is 0x0000. However, I believe this is option and I think I remember receiving packets this way.

 

Oh, the pcap files are from wireshark.

Josh
Software is never really finished, it's just an acceptable level of broken
0 Kudos
Message 7 of 29
(5,517 Views)

@JW-L3CE wrote:

Unfortunately, I need the net address to specify the card I'm using. This computer has 6 ports. 4 will be used for GigE Vision, and 1 is this custom interface.

 


I seem to remember some monkey business about having to use the primary port in some situations (though that might be RT systems with TCP, I forgot and couldn't find it).

 

look at the udp send/recieve example VIs (help>find examples).  See if you can run those as a test.  Also try localhost?

 

 

-Barrett
CLD
0 Kudos
Message 8 of 29
(5,516 Views)

blawson: I hope I wouldn't have to only use the primary port. That would ruin the entire design. I'll be sending out on about 5 ports simultaneously.

 

What I tried recently:

 

1) After looking at the examples, I noticed that they don't wire the address. I tried opening two connections: One with the port and IP for writing, and one with just the port (the same port) for reading. The code is attached. Same problem.

 

2) Someone coded up a Ruby executable to display any UDP packets reaching it. This ran in parallel with the LabVIEW code. Nothing was reported.

 

3) Set the Host IP to 1.1.1.1 on a coworker suggestion. LabVIEW errored.

 

My hunch is that something in the packets from this unit are causing it to be dropped. I can't imagine what is wrong because wireshark doesn't flag anything in the packets. We're also scanned over them a few times looking for things that stand out.

Josh
Software is never really finished, it's just an acceptable level of broken
0 Kudos
Message 9 of 29
(5,500 Views)

JW-L3CE wrote:

2) Someone coded up a Ruby executable to display any UDP packets reaching it. This ran in parallel with the LabVIEW code. Nothing was reported.


What are you trying to say here?  The Ruby executable didn't read any UDP packets either, or it didn't report any errors?  Only one application at a time can open a specific port, so running in parallel is more likely to generate errors than useful information.

0 Kudos
Message 10 of 29
(5,495 Views)