mbSession.ReadStatusByte() hangs program within callback mechanism for USBTMC instrument

[RobS19]

I'm using Visual Studio vb.net 2008 and the NI-VISA.net libraries (VisaNS.dll) Version 8.9.35.108 and am having trouble getting ReadStatusByte() to return a value.  I used the example program Service Request.2008 as-is and it worked great for GPIB. But I want to do the same thing with a USBTMC device, so I changed all references to GpibSession to MessageBasedSession.  I first tested the modification using GPIB and everything ran as expected.  Switched to USB and as soon as the SRQ triggered the event and passed control to the callback handler routine (OnServiceRequest) the program stops at ReadStatusByte and does not continue. Any attempts to access the form are met with a "Program Not Responding" Message.

I tried two different USB instruments: A PicoTest M3500A DMM and a Tektronix MSO2014 Oscilloscope. 

I've attached the NI-Spy files for the GPIB and USB runs. Any help would be appreciated.

Thanks,

Rob

[Al.B]

Hi Rob,

The fact that only a start time is shown for the status byte is definately indicating that the readstatusbyte call is never returning.  To get a better idea why this may happen, I have a few questions to clarify:

1. Does this behavior occur every time you run the code?

2. If you disable the readStatusByte call, does the hang occur on the next VISA command?  If not, what behavior do you see?

3. Can you test this on another PC?

I plan to discuss this with R&D to see what may be going on here - I'll update you if I find out anything!

[RobS19]

Hi Al,

Thanks for the reply.

In reference to your questions:

1. Yes it happens every time I run the code.

2. The code does not lock-up if I disable the call to ReadStatusByte(), It prints the text returned from mb.ReadString(). BUT if I try to run the disabled code using a GPIB address, the code only enters the callback routine the first time. After that the SRQ is ignored (it doesn't re-Start: ibnotify callback), but the code does not lock-up.

3. I got the same results on another computer running VisaNS.dll version 8.5.20.310.

I've attached another NI-Spy capture which recorded the USB run and the GPIB run. I also attached the zipped vb.net Project.

I'm trying to find an LXI compliant LAN instrument so I can see how that behaves running this code.

---

@Al B wrote:

Hi Rob,

The fact that only a start time is shown for the status byte is definately indicating that the readstatusbyte call is never returning.  To get a better idea why this may happen, I have a few questions to clarify:

1. Does this behavior occur every time you run the code?

2. If you disable the readStatusByte call, does the hang occur on the next VISA command?  If not, what behavior do you see?

3. Can you test this on another PC?

I plan to discuss this with R&D to see what may be going on here - I'll update you if I find out anything!

---

[RobS19]

Hi Al,

TCP/IP VXI-11 Instruments behave properly

[RobS19]

Al,

Any updates for this issue?

Thanks.

[Al.B]

Hi RobS,

I'm really sorry about the delay on this - I am in contact with R&D and will let you know as soon as I have any next steps.

[Al.B]

Hi RobS,

Just wanted to let you know that R&D has reproduced this behavior and is looking into possible causes.  I'll let you know what they find

[RobS19]

Thanks Al.  Awaiting anxiously!.

[Al.B]

Hi Rob,

This issue has been reported as Corrective Action Request #257985, and will be addressed by the VISA development team so that a fix will be considered in a later version of the driver.  I am currently checking with R&D to see if there are any workarounds at this time.

[RobS19]

I just downloaded the latest version (5.0.3) of NI-VISA library for .NET (VisaNS) and re-compiled my project - making sure to delete any references to the older versions.  It appears that the problem with the USBTMC has not been resolved in the latest release.

Any idea as to when or if this issue will be resolved? We have built a good bit of our code around your framework but our project is at the point now that if we don't have some sort of resolution or work-around soon, we will need to look at using VISA-COM.