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

[kevin jones]

I have an external device sending UDP datagrams to port 30002. It transmits a 1300 byte datagram every 32ms.

My LabVIEW application runs on a Windows XP PC and simply reads the datagram, applies some formatting and saves to disk.

I am finding that interacting with the PC - key presses, mouse activity, etc. occasionally causes error 56 during UDP read. Most key presses in my LabVIEW application initiate a UDP datagram to be sent to the external device on a different port. But others, such as the save to disk button, do not, yet these can still cause the error.

Occasional lost datagrams can be tolerated but the real problem is that the error does not clear, even closing the UDP connection and re-opening it does not clear the error. I have to stop the VI and restart it, which is not acceptable when the application goes live. The fact that once the VI is restarted the communication is resumed prooves to me that the external device did not stop sending the datagrams.

If the PC is left running without interaction the application runs without errors for days on end.

I have set the UDP receive buffer size to 2^24, which is enough to buffer about 6 minutes worth of messages, this should be plenty of time to allow windows to go off and service background tasks.

I don't think there is much I can do about it with LabVIEW as it would appear to be a problem with Winsock.

Has anyone else experienced this ? Any tips to get around it ? Is there a way to monitor how full the UDP receive buffer is ?

[PhillipBrooks]

A UDP Error # 56 simply means that the UDP read received nothing in the timout period you specified. you could increase the timeout, or more simply discard the error. See this post: http://forums.ni.com/ni/board/message?board.id=170&message.id=232028

As far as the error "not clearing", it sounds like you are using a shift register inside a loop to pass the error out of the previous UDP read. If you don't initialize the shift register, it will contain the last data stored ontil you close an reload the VI.

Message Edited by Phillip Brooks on 09-27-2007 07:22 AM

[kevin jones]

Thanks for your advice Philip. I had already tried disgarding the error as suggested in the post that you referenced. However I do not have the error input wired, default is no error, so after the error occurs the first time a new error must be being generated every time that UDP read is called, until I stop the VI and restart it. My time out is set to 500ms.

I also found this old thread which I think sounds similar to what I am experiencing:

http://forums.ni.com/ni/board/message?board.id=170&message.id=43971&requireLogin=False

I spent this morning running the LabVIEW VI in the background whilst doing some heavy duty number crunching in Excel and so far the VI has not produced the error, so I am starting to think it is only user interaction in LabVIEW window that is the cause but more testing is required.

Is there a difference between using the 'UDP close' while the main VI is running, and stopping the main VI ?

I.E. does stopping the main VI also flush the UDP receive buffer ?

Thanks !

[PhillipBrooks]

Using the stop button (Abort Execution) is generally speaking a bad idea. This is for development purposes only and should be disabled from the VI properties if the VI is run by operators (set "Show Abort Button" to false). You should try to close any references (file, network, VISA, etc...) handles gracefully. The rule of thumb is to close references in the VI where they are opened. This makes it easier to troubleshoot and keeps your code modular. I've exhausted VISA handle references during development (by using abort button ) and had to quit LabVIEW to continue working.

Since UDP is not a guarenteed delivery and your expected message rate is much faster than your wait time (~10x), I would add a shift register to the while loop performing the UDP Reads and initialize it to zero. If you receive an error 56 (timeout) increment the contents of the shift register by one. If no error, set it to zero. Exit the loop if there is an error OTHER THAN 56 or if the value in the shift register is greater than, say, 10 (~ 5 seconds?)

[kevin jones]

Thanks again Philip for your input. When I said 'stopping the VI' I meant exiting the loop that contains the UDP read, closing the UDP connection etc, terminating gracefully, I never use the abort button.

I had already implemented an error counter, similar to what you describe, which when triggerred closes the UDP connection and opens a new one. But as I said this does not help, the very next UDP read produces error 56 again, I have to stop my program (no VIs running) and restart, and then comms are resumed.

It seems to me that the UDP port is getting locked up some how, as I mentioned, I think it is something at the OS level.

[Robert_Lee_NIUK]

Hi Kevin,

Having looked at your correspondence, it is unclear why the errors are occurring. Could I ask you to try a couple of things? Try and put some timestamps\tick counts in your loops so we can get an idea of how this value varies when we start performing other LabVIEW tasks. To do this, place the UDP code in a sequence structure fram and place a tick count in a frame before and after. Minus the two values and we'll get an idea of exactly how long it's taking to perform those actions. Also, how much delay do you have in the loop (i.e. what execution timing value are you using).

Let me know if this helps at all

Good luck!

[kevin jones]

Hi Rob,

Thanks for taking an interest.

The program loop time is determined by the transmission rate of the external device. The speed can be set to different data rates, but I am mainly using 31.25Hz (32ms), although I can increase it to 250Hz (4ms). If I follow your advice about adding tick counts, the value after UDP read - value before UDP read = close to the data rate of the external device, i.e. 31ms at 31.25Hz, 3ms at 250Hz.This suggests that the rest of my code executes in around 1ms.

The exception to this is when I start clicking controls in the LabView window or in other applications such as Explorer, Outlook etc, whereby the time can increase momentarily to around 60 / 70 ms. I believe several of these delays can cause Error 56 if the UDP buffer is not read before my 500ms time-out. It is quite difficult to cause the error though and if the PC is left alone the error does not occur and the program will run for days (maybe forever!). What I don't understand is that once I get an error 56 it does not recover from this condition, all subsequent UDP reads result in error 56 until I stop my program and restart it.

I found this very old link which I think is similar to my problem:

http://forums.ni.com/ni/board/message?board.id=170&message.id=43971&requireLogin=False

It suggests this is a problem with winsock and the windows UI thread, which I guess still exists, as XP came out around 2003.

Up to now I have only tried running my LabView program in the development environment, i.e. as a llb, I am wondering whether it would help to build an executable.

Thanks

Kevin

[JamesC]

Hi Kevin,

Please can you try running the attached VIs UDP Write and UDP Read. Please put all three VIs into the same directory.

This code works fine for me, so the only thing I can think of that would stop your code from leaving a error state of 56, is a firewall issue. However as you say you can run the code fine until you get an error of 56 then that seems to suggest it is not a firewall issue, and perhaps it has something to do with your Timeout removal subVI.

Regards
JamesC
NIUK and Ireland

[kevin jones]

Hi James,

Thanks for trying to help. Unfortunately we only have LabVIEW 8.0, we're not on maintenance. Any chance you could post images of the block diagrams ?

Thanks

Kevin

[Robert_Lee_NIUK]

Hi Kevin,

I have reverted the files back to version 8 for you.