From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Measurement Studio for .NET Languages

cancel
Showing results for 
Search instead for 
Did you mean: 

Asynchronous I/O not ending on exception (C# - NI4882)

Solved!
Go to solution
I have some weird things happening in the GPIB class when working with the NI4882 library. When an instrument (in this case a Voltage Standard) is not on, an exception is thrown during device.EndReadString() when trying to query the instrument for the first time. Once this happens, every other GPIB call (even ones to different drivers on different addresses) throws an InvalidOperationException saying that an Asynchronous I/O operation is in progress. 
 
From looking up NationalInstruments docs, it seems like 'EndReadString()' should end this operation. My guess is that it is not doing that when an exception is thrown. I used the 'GetCurrentStatus()' method, and it is returning 'None', which the docs say means that an Async I/O operation is in progress.
 
Any idea how to stop this process? (I tried the 'AbortAsynchronousIO()' method, but that doesn't seem to work)
 
Thanks for any help you can provide.
0 Kudos
Message 1 of 3
(2,167 Views)
Solution
Accepted by topic author J33pFan

I don't understand one thing: if your instrument is not on then exception should be thrown way before you are allowed to call EndReadString, when sending the command or when calling BeginRead.  To make sure you don't call  EndReadString prematurely you should always call it from the callback (AsyncCallback parameter) given to BeginRead.  Having said that I also had problems and found this implementation of asynchronous IO a bit awkward, a more straightforward way to achieve asynchronous reading is to use normal blocking calls issued from a background thread (actually this is what I'm doing, you will find my gpib code on CodeProject), this works well and I can more easily know what the reason of an exception is.

Message 2 of 3
(2,101 Views)

Thanks. We have done similarly, using the normal blocking calls from within a Task, which seems to have fixed all of the asynchronous issues we were having.

0 Kudos
Message 3 of 3
(2,078 Views)