How can I wait for VISA-TCP write to complete?

[Mark_Yedinak]

How can I get an application to wait for a VISA-TCP to wait for all of the data to be written? I have tried using both the synchronous and asynchronous modes of the VISA write but the application is not waiting for all of the data to be transmitted. Using a LAN analyzer I can see that the program continues on even though the lower level drivers handling the TCP stack are still writing data out to the device. Unfortunately for the test that I am doing I cannot rely on a response from the device to indicate that it has received all of the data. A look through the VISA events didn't find anything remotely related to this.

My application is repeatedly opening a connection to the device, sending some data and then closing the connection. This application is simulating a print queue and traces of actual print queues show that it waits to establish a new connection until the previous job has been completed. My LabVIEW application has this logic however from watching the program execution as well as the network trace it is clear that the application is not actually waiting until the data has actually been completely transmitted. Once the VISA write passes the data to the stack (some lower level code, Winsock possibly) it returns immediately.

Any thoughts?

Cross posted on LAVA: http://lavag.org/topic/11467-how-can-i-wait-for-visa-tcp-write-to-complete/

Message Edited by Mark Yedinak on 11-19-2009 08:39 PM

[PJS]

Mark,

Is it possible to create a virtual instrument that is running resident on your machine?  Use another synchronous write to this virtual instrument after you send the data to the device under test, then you can hold up execution till you receive data to this new virtual instrument?  

Just a thought rather than using a static wait.  Another, more exotic thought if you are using Windows, would be to use the dotNet TCP assemblies, or if the device has drivers, interface directly with those drivers.

All are work arounds to be sure, but maybe something will shake out from alternative thinking.

[Mark_Yedinak]

Thanks for the suggestions. Unfortunately these wouldn't really solve the problem that I am seeing. I want to be clear that I am not trying to use static waits in the application. What I want is for the application to wait until all of the data is actually transmitted. The way it is wokring now I use the VISA write and it is returning immediately because it has successfully handed the data off to the lower level stack. However the data is actually buffered in the stack and is sent out much more slowly to the device. I need to be able to wait on this data transmission. The primary reaon I am focused on VISA is thath this is part of an existing library that is already built using VISA. I don't want to have to rewrite the whole thing. The library is a generic connection class that allows applications to connect to a device using multiple interface types. It would be nice to rewrite this using native LVOOP but I don't have that kind of time.

[CoastalMaineBird]

I've not used VISA for TCP operations, but could you establish ANOTHER connection immediateley after sending?

Something like:

• Open Connection
• Send Data
• Close Connection
• Open Connection
• Close Connection

Maybe (I'm not sure) the second OPEN would wait until the actual queue was empty. 

[Mark_Yedinak]

No, this would not work. The device under test is capable of accepting multiple connections. In your example the second open would simply establish another connection. This is a valid test and it is effectively what is happening now in the test application. However I also want to have a mode where the connections are serialized and not established until all the data has been transmitted. I have been discussing this with NI and they have said that the synchronous/asychronous modes should work they way I want. However they aren't and this may be a bug in VISA.

[CoastalMaineBird]

Could you establish a dummy receiver within your LabVIEW code?

Transmit the data both to your real device and a dummy receiver?

When the dummy receiver sees it, that means it's really gone out the door, and it signals your main loop that it's gone. 

[Mark_Yedinak]

the dummy receiver would most likely receive the data faster than the device. In addition, the time it takes for the device to process the data is dependent on the contents of the data. Some things are processed very quickly and some things take longer to process therefore slowing up the data reception. Ultimately I believe that this is a bug in the VISA driver. Since it has both asynchronous and synchronous modes for transmitting the data it should hoonr that setting.