UDP error 56 seems to be caused by UI thread and does not clear without restarting VI

[kevin jones]

Hi Rob and James,

Thanks for the VIs. They behave as expected, i.e when the Timeout is triggerred from UDP Write.vi, UDP Read.vi lights the timeout Indicator and error code is 56 but clears to 0, and when the UDP write.vi starts sending data again the timeout light goes out and error code is 0.

I can achieve this effect in my own program by deliberately setting a timout that is too short to collect every datagram that is transmitted. E.G. if datagrams are being sent every 16ms and I set timeout to 10ms, I get error 56 every other time my UDP read function is called. The key thing here is the program recovers and the error code reverts to 0 when there is a UDP datagram in the buffer.

However this is not the same as my problem, which is that when the PC is doing other stuff (servicing mouse/keyboard activity) and not reading the UDP buffer, error 56 occurs. Once error 56 is activated, each subsequent call to the UDP read function gives error 56, even though my external instrument keeps transmitting datagrams to the same port, and once the LabView program is restarted it resumes reading the UDP buffer correctly. Simply closing the port and reopening has no effect.

Does stopping all VIs cause the UDP buffer to be flushed, whereas closing the port leaves it intact ?

Is there anything else that could cause error 56 ?

Thanks

Kevin

[PhillipBrooks]

I just went back and read your original post. You stated that yuo are receiving 1300 bytes from the source device. Are you wiring the Max Size input as 1300?

I recall that there are some notes in the online help about using a value other than the default (548) and that "Windows might return an error becasue the function cannot read fewer bytes than are in a packet". Maybe your source is sending out messages that are not 1300 bytes in length? You might want to use Ethereal to capture the ethernet data and see if the packets are the right length from the source...

The error that Windows might return [ gotta love that description from the LV online help 🙂 ]  may also indicate that the connection ID is no longer valid (Windows discarded/cleared the handle) and you might need to open a new connection ID.

Just some ideas...

Message Edited by Phillip Brooks on 10-23-2007 07:57 AM

[kevin jones]

Hi Philip,

The source device transmits 1316, 676, 356 or 196 bytes depending on if it is averaging by 1, 2, 4 or 8. I have set read bytes to 1500 to cover all eventualities. The online help only mentions a minimum limit of 548, I'm assuming as long as the bytes to read is >= the bytes in the datagram that it will be ok. Anyway I tried setting the number of read bytes to match exactly the number of transmitted bytes but can still get the error 56 problem to occur.

I have also tried closing the connection ID and reopening when error 56 occurs, but I get error 56 straight away with the new connection ID. Only stopping all VIs clears allows the UDP read to start again without errors.

Thanks

Kevin