Add an "Abort" event to VISA reads and writes

[Mark_Yedinak]

The current VISA read and write primatives do not have the ability to abort early. Under many circumstances if the timeout values are short this is not an issue but it can be an issue if a long timeout is required. The current work around is to use a short timeout value and loop continually ignoring the individual timeouts until a threshold has passed and then pass the timeout error out. This apporach requires the extra code to "monitor" the process of the communication. It also requires shift registers and associated logic to maintain the data. It would be desireable to simply set the timeout for the desired value and have a separate VISA property that can be set cause the current operation to abort.

[RavensFan]

Can you give a situation where you would need to abort a VISA function before the timeout is expired?  And how long of a timeout are you using in such a situation?

[Mark_Yedinak]

In the testing of our products we have timeouts that are 3 minutes long or longer in some cases. Also, it is not unusual to have one minute timeouts when using TCP connection, which are possible with VISA. If the user would like to terminate the application they will need to wait until the VISA timeout has expired unless the action (read or write) is wrapped in the loop with a short timeout and a check of a notifier for an abort each iteration.

Actually this suggestion could be extended to the TCP and UDP primatives as well as any other events with timeout events suh as queues or notifiers.

Message Edited by Mark Yedinak on 09-09-2009 02:12 PM

[Mads]

Kudos

This is definitely something that should be available on all functions that may be asked to wait for a long time and currently does not give you a way to stop the waiting (VISA, TCP, UDP, the wait functions etc.)

OpenG has a wait function that lets you stop it by setting an occurence by the way, very useful.

[rolfk]

Well, to abort queues, notifers, TCP/IP and UDP reads (writes for most of them only theoretically) you can always close the original reference. This will terminate all waiting operations. Unfortunately VISA seems to be an exception here. VISA Close does not terminate a pending Read operation. I have created a VI here (sorry the forum is in German) that remedies this. Adding this call to the VISA Close would be rather simple for NI, since VISA itself does have that capability, it is just not used in LabVIEW so far.

Rolf Kalbermatter

[Mark_Yedinak]

However you may not necessary want to close the connection. You may simply want to abort the current operation. Granted in most cases you would probably close teh connection as well but that is a harsh method of getting the abort.

[andre.buurman@carya]

The library call Rolf is doing can also be put in its own subVI to only do an abort without close.

[smmarlow]

I have wanted this feature for a very long time.  The reference-based sync objects (queue, notifier) terminate waits and return an error of the reference is closed while a function is waiting.  Unfortunately for VISA, LabVIEW becomes unstable if you close a VISA session while the READ function is waiting.  Not only does it not terminate the wait, LabVIEW often times crashes when the timeout period expires.  I agree with Rolf.  You should be able to terminate a wait by closing a VISA ref.  There should also be a VISA Abort function that terminates all waiting read/write functions for a session when executed.

[Brian_Powell]

Interesting.  I haven't seen a bug report about the instability of LabVIEW when you close the VISA session with I/O in progress.  And I'm pretty sure such a report would make its way to me.  Can you reproduce this in LabVIEW 2010?

[GregFreeman]

Don't the VISA VIs just wrap the functions existing in the VISA32.dll? If so, would an abort even be an option? I don't know enough about that lower level stuff to have an idea, maybe it can be done and I'm just an ignoramus

[rolfk]

@for(imstuck): Yes the VISA nodes are mostly wrappers around visa32.dll (or whatever shared library format is used on non-windows platforms) with some thin sugar layer to make VISA a bit more LabVIEW feelish. And the workaround I have suggested earlier simply calls one of those API functions in visa32 passing it the LabVIEW VISA refnum in a way that the orginal VISA refnum is passed to the function.