06-05-2013 11:04 AM
Hi,
I have a simple UDP reciever custom device for VeriStand which uses a timed loop. It has an infinite timeout so that I can listen at the port constantly. Everytime I undeploy I cause an Error: -307730 Error Message: NI Veristand: One or more asynchronous custom devices failed to shut down properly and were aborted by the Veristand Engine.
Does anyone know of a way to interrupt the UDP Read function when it is waiting for a packet? What does VeriStand do when it overrides this behavior, for instance does it close the network connection as the device undeploys? Does the "Stop.vi" from the custom device template execute?
Similiar question for Visa Read with a long timeout (>10s roughly). Does VeriStand close the Visa Session? Does VeriStand just kill the timed loop and let the rest of the custom device finish?
Please note, if I shorten the timeout to 1s or less the custom device can undeploy with no issues.
Thanks,
Brent
Solved! Go to Solution.
06-06-2013 10:27 AM
Hi,
i found that this is a reported bug in VeriStand 2010 which was reported as Error -307730 when undeploying an asynchronous custom device as Corrective Action Request (CAR)#288431.
Do you use VeriStand 2010? If yes, then I will check if the problem is solved in VeriStand 2011.
Regards,
Michael
06-06-2013 11:07 AM - edited 06-06-2013 11:09 AM
Hey,
I am using VeriStand 2011. I'm not entirely sure what I'm seeing is a bug. I think its just that the custom device thread gets caught waiting for the UDP Read function timeout, but it doesn't timeout so VeriStand overrides the function. What I would like to know is how can I override the function and ensure the that network connection gets shut down properly. Or does VeriStand just override the timed loop in an asyncronous custom device allowing the code outside the loop to finish? If that is the case, that would be great.
Also, does anyone know how long VeriStand is willing to wait before forcing a custom device to shut down?
Brent
This applies to any function that has a timeout where the timeout is longer than the allowance of VeriStand's shutdown procedure.
06-06-2013 11:14 AM
Brent,
You should have a way to interrupt your UDP operations to check for system status. The UDP open will create the buffer allowing data to be received on that port. As long as a read occurs to clear the buffer before too much data overflows the buffer then you should be fine. By leaving a timeout of -1 that loop is blocking so that is why VeriStand is having to shutdown the loop.
You should have a timeout case for your UDP/TCP operations for times of low activity so you can check a channel to shutdown the custom device.