VISA doesn't talk to USB Tektronix oscilloscope on RH4 WS Linux although works well on Windows XP

[Sarah_R]

Have you tried removing the termination character, to see if that changes the behavior at all.

[DVV]

>Have you tried removing the termination character, to see if that changes the behavior at all.
I tried - no effect, everything is the same.

I have more information now which makes me believe that it has nothing to do
with how I do things but rather how VISA communicate with a kernel USB stack and the scope:

I found a post  which suggests that that VISA
works fine the very first session after a computer reboot or
plugging/unplugging a device. The next session VISA fails to
communicate with the device. The session means opening the
device, communicating with it and closing it.

It's impossible to see this behavior with NIvisaic because the first
thing it does is trying to open each of the listed devices. So it
opens and closes the device and then if I open it manually it already
doesn't work according to the post.

To check for that I compiled an example which can be found  in
/usr/local/vxipnp/linux/NIvisa/Examples/C/General/RdWrt.c after
installing VISA 4.2-Linux with the only change in a name of a device
which is opened from 
"GPIB0::2::INSTR" to "USB0::0x0699::0x036A::C031476::INSTR"
The example does exactly what I tried to do with NIVisaic:

1) open the device with viOpen
2) write *IDN?\n with viWrite
3) read the response with viRead
4) close the device with viClose

..plus stuff about opening and closing a Resource Manager...

The example INDEED works successfully but only once after either a computer reboot or
after plugging/unplugging the scope! The second time I run it the
viWrite exits with 0xBFFF0015 code.

I also extended the example to make it to execute a few pairs of viWrite/viRead
withing the same session:

1) open the device with viOpen

2) write *IDN?\n with viWrite
3) read the response with viRead

4) write *IDN?\n with viWrite
5) read the response with viRead
.
.
.

N) close the device with viClose

it also works fine, but again only one time...

[Sarah_R]

I am currently looking into this issue. I will let you know what I am able to find.

Thank you for your patience.

[Sarah_R]

If possible I would like to get a bit more information from you. I would like to troubleshoot the issue a bit more and debug the situation from a lower level. This will allow us to see the source of the timeout error.

If you have a bus analyzer available and are able to give us the results, we will be able to continue debugging this further.

Please let me know. Thanks

[DVV]

>If possible I would like to get a bit more information from you. I would like to troubleshoot the issue a bit more and debug the situation from a lower level. This will allow us to >see the source of the timeout error.
>If you have a bus analyzer available and are able to give us the results, we will be able to continue debugging this further.

We don't have one here. But I'm willing to install and use any software which can be used as a bus analyzer you supply me with or you point me to.

Regards,
DVV.

[Sarah_R]

An option to use would be the following:
http://www.newfreedownloads.com/Windows-Utilities/Miscellaneous/USBTrace.html

We have not used it, but it should do what is expected.

Thanks

[Sarah_R]

DVV,

The previously posted link, is for Windows only OS. I will have to do some research in software based Bus Analyzer for Linux. I will let you know as soon as I am able to find an option.

Sorry about that.

[DVV]

Here is a USBTrace log for a successfull interaction with the scope on Windows XP (as far as I understand there is a summary of all of the transactions (sequences, 124 of them) in the top of the page plus the detailed information on each transaction available downward in the page):

Sequences correspond to the following actions:
0-60     Openning NIvisaic
61-112   Openning the scope (double clicking on scope device in NIvisaic window)
113-116    Writing "*IDN?\n"
117-124    Reading the response

No USB traffic seems to correspond to closing the scope and exiting the NIvisaic program.

[Sarah_R]

Thank you very much for the bus analyzer log for the Windows end of this issue. However, to look into it even further we need to get a capture from a USB Analyzer on the Linux end. This will allow us to research into the low level commands and understand exactly what is happening. A popular brand is CATC.

Please let me now if there is any chance you will be able to get the USB Analyzer hardware and software, to perform this capture. Until we are able to get this capture, we unfortunately are unable to move forward.

Thanks

[Sarah_R]

DVV,

Through testing out the equipment here at NI, we were able to find the following information:

Facts:
We set up a 1002B USB Tek scope with a system running RedHat Linux 4.  Initially, VISAIC would open a session to the Tek scope, but we would always get the timeout error when trying to Write.  We tried on RedHat 5 and got the same result. 

We set up the CATC analyzer with the USB Tek scope and the system running RedHat Linux 4.  We narrowed it down to an issue between the Linux kernel and the Tek scope.  It actually has nothing to do with VISA.  When using the analyzer, if we turn trace recording on before the device is plugged in and turn it off after it's plugged in, the device is then able to receive a Write and seems to work fine with the Linux kernel.  If tracing is not on during that time, the Linux kernel will not send data (Bulk transfers) to the device for some reason.  So since Linux won't interact with the device further than getting info about it (Control transfers), VISA Writes timeout.  

Thoughts:
When we used the hardware analyzer, it must have minimally slowed down the USB communication between the Linux machine and the scope to make this change in behavior.   When the initial plugging in of the Tek scope happens, RedHat 4's USB response speed could be too fast for the Tek scope.  Slowing the initial connection down makes things work between the kernel and scope, so it could be the fault of either.  It may be a race condition in the RedHat kernel. 

The Tek scope was probably tested with Windows but not Linux.  It's probably too old and slow to work with some Linux kernels.  

Potential theoretical workarounds:
Using a slower computer or installing debug version of the Linux kernel could slow that connecting down enough to work for a device this slow.  They could also try with newer Tek scopes.

Thanks