always VI_ERROR_RSRC_BUSY on reads, can't recover

[magtech]

I am (mostly) able to communicate with my Tektronix TDS2014B digital
oscilloscope via USB using the PyVISA software with Ubuntu Linux 2.6.15.

I have all the National Instruments software running and I figure that since I
can communicate with the scope at all shows that I must have most things setup
correctly. I only started doing all this within the last week, so I should have all the
latest NI software and drivers.

The problem I am having occurs if I request a read from the device when the
device isn't ready to reply or the device has a timeout.

For example, if I send a:

cro.ask("*cal?")

and the calibration takes longer than the timeout then all subsequent reads will
fail and I will lose control of the scope.

Here is a NIspy listing of an example where I can successfully request the ID
string (1,2), I perform a read (3) which causes a read timeout, and further ID
string (4,5) requests fail.

1.  viWrite (0x08273290, "*idn?..", 7, 7)
Process ID: 0x00006766         Thread ID: 0xB7DEE8E0
Start Time: 10:09:27.743       Call Duration 00:00:00.003
Status: 0 (VI_SUCCESS)

2.  viRead (0x08273290, "TEKTRONIX,TDS 2014B,C...", 20480, 48)
Process ID: 0x00006766         Thread ID: 0xB7DEE8E0
Start Time: 10:09:27.747       Call Duration 00:00:00.070
Status: 0 (VI_SUCCESS)

3.  viRead (0x08273290, 0x08283040, 20480, 0)
Process ID: 0x00006766         Thread ID: 0xB7DEE8E0
Start Time: 10:09:37.340       Call Duration 00:00:05.028
Status: 0xBFFF0015 (VI_ERROR_TMO)

4.  viWrite (0x08273290, "*idn?..", 7, 7)
Process ID: 0x00006766         Thread ID: 0xB7DEE8E0
Start Time: 10:09:44.243       Call Duration 00:00:00.001
Status: 0 (VI_SUCCESS)

5.  viRead (0x08273290, 0x08283040, 20480, 0)
Process ID: 0x00006766         Thread ID: 0xB7DEE8E0
Start Time: 10:09:44.244       Call Duration 00:00:00.136
Status: 0xBFFF0072 (VI_ERROR_RSRC_BUSY)

I must point out that writes succeed, just the reads fail. For example,
I can reset the CRO and change settings so the USB connection is still
working - but only one way!

If I want to perform reads, I have to unplug the USB, close Python, replug USB,
restart Python and (most times) I will be able to recover the connection.

I have tried doing a flush, a clear, close then re-open. I just get the same
"VI_ERROR_RSRC_BUSY" error on read or I start getting timeouts on
both reads and writes.

Is there a way to recover from this point? Is the problem with PyVISA, NI-VISA, or the instrument?

[SMesser]

Okay - it sounds like you've gotten further than I have; I'm trying to use Python 2.4 under Linux SUSE 10.0 to communicate with a Tektronix TDS2014B over USB. I've managed to get the low-level USB monitors ("usbview" and "USB Devices" on my system menu) to identify the scope. When I try python's visa.get_instruments_list(), it recognizes there's a USB device attached iff the scope's plugged in & turned on, but I can't read OR write. I get no error messages - but the scope doesn't respond to commangs and doesn't reply. nispy reports that my writes result in VI_ERROR_TMO (timeout), and my reads also give VI_ERROR_RSRC_BUSY

Since the USB monitor stuff seems happy, I've been assuming the instrument was okay. Early on I had some lower-level issues which were fixed by going into the scope's Utility>Options>Rear USB Port and setting it to "Computer" rather than the default "Auto Detect." Also, FYI, Linux re-binds it to a different /dev/usbdev* file if you alter the scope's setting for Utility>Options>GPIB Setup>Address - pyVISA doesn't seem to be affected, though.

Other things I've attempted:
Since the Tektronix manual mentions the USB uses USBTMC, an "IEEE488.2-like interface over USB," I've tried to install a GPIB driver package (gpib-3.2.03, which I found on a Debian developers' page... ) That package's makefile has been crashing during install, but I'm not sure how much it'll help. It does, however, include a directory usb/ni_usb_gpib/

I've also tried downloading and installing a low-level "pyusb-0.3.5" package from SourceForge.net, but I haven't tried using it. From that package's documentation, it looks like there's an extra level that goes between it and the ASCII communication we're interested in.

Please keep me posted if you make progress (or recognize what I'm doing wrong.)

Thanks

I've also tried raw reads & writes to the /dev/usbdev* ports, but nothing came of that.

[SMesser]

erm... it seems that I _can_ write to the scope - now... I've a nispy session open at the moment; the first couple of writes failed; later ones succeeded. The only changes that I recall doing in between were flipping through the scope menus to get the right submenu names for the previous posting... dunno.

[SMesser]

I tried sending a tech-support request to Tektronix; their reply follows:
----begin quote----
I also had similiar issues communicating with a TDS2000B using Fedora
and NI-VISA to read responses from the scope. NI-VISA interactive
control could ID the scope however. After rebooting the scope and having VISA
rescan for USB devices it then started working, although not as
reliable as I would've expected.

It might be worth the effort to verify the communication with a Windows
machine using a free program called OpenChoice desktop from
http://www2.tek.com/cmswpt/swdetails.lotr?ct=SW&cs=Application&ci=5302
. At least this would establish the scope does respond from queries.

----end quote----

I haven't yet tried the Windows-based communication, but since we're getting the same problems on three different distributions of linux, three different computers, and at least four different scopes (I've tried with two), I doubt it's torched hardware. More likely a Linux vs. Windows difference in either the NI-VISA driver or the computer's handling of USB communication...

[magtech]

I'm in Australia and I've sent out a couple emails to Tektronix support and I haven't heard anything from them except to ask about my contact details. Which contact address did you use?

I had various difficulties getting NI-VISA working on Linux. It requires so many modules and applications to run in the background just to send a few simple ASCII commands. Even if you can see the scope in the instrument list, doesn't mean you will be able to communicate with it.

* make sure you run the "driverwizard" to create your *.inf file and then place it in /etc/natinst/nipal/inf/. My driverwizard had the USB connection option greyed out but there were USB-like options in the PXI/PCI screens which I used instead.
* start /etc/init.d/nipxirmu and /etc/init.d/nipal
* make sure lsmod lists a whole load of ni stuff, e.g.
e.g.
$ sudo /etc/init.d/nipxirmu start; sudo /etc/init.d/nipal start
$ lsmod | grep ni
nipxirmk              124372  0
nidimk                375360  1 nipxirmk
niorbk                129140  2 nipxirmk,nidimk
nipalk               1293808  4 nipxirmk,nidimk,niorbk
nikal                  76564  2 nipalk
usbcore               152644  6 nikal,ftdi_sio,usbserial,ehci_hcd,ohci_hcd

Not sure if I need all these modules, but at least the connection (sort of) works. Initially I found that my system wanted to load the usbhid driver for my device, I had to remove it the first few times until I got the NI system to take control of the USB interface properly.

I've pretty well given up on the NI solution and I'm now talking directly to the CRO using just pyusb and libusb. I've studied the USBTMC and USBTMC-USB488 standards and they are fairly straight forward as far as USB standards go. I have successfully done a "*IDN?" using just pyusb but I'm can't seem to initialise the TDS2014B in the first place without using the pyVisa code. Even then, if I run my test program to read the ID string from the scope, it will fail about 20% of the time for no reason. I suspect this scope might have some problems and the release notes for the latest firmware version indicate that there are problems with the USB interface and USBTMC compliance.

I really don't understand why they put all this GPIB stuff in the way of what is a very simple ASCII interface ... Next time I will buy an ethernet based CRO, the extra cost far outweighs the time I've spent trying get this silly GPIB-over-USB thing working *reliably*. All our other instruments are ethernet based and to communicate with them you: a) telnet to the instrument (from any operating system); and b) type the command in plain text e.g. "*idn?". Far simpler and more reliable from my experience.

[SMesser]

I also have moved away from NI-VISA for communicating to the scope and am focussing on pyUSB. Hopefully I'll get the "*IDN?" working today... will keep you posted. Do you have a link for the USBTMC & USBTMC-488 standards? I haven't tried programming over USB before, and was expecting protocols more like the RS-232 interfaces we used for the previous scopes.

As for contacting Tektronix, I think I just used the "My Product Support" link at http://www.tek.com/service (It might also make a difference that we've ordered 16 scopes from them in the past six months, about half of which are the TDS2014B model.) My guess is that they are doing GPIB-over-USB since they've had straight GPIB for years and that's working fairly reliably. Probably figured GPIB-over-USB would be easier on their programmers than straight USB.

Thanks for the NI-VISA / Linux details

[SMesser]

I've spent all day playing with pyusb-0.3.5, and haven't had much progress. Python says it's (usually) able to successfully write to the scope on endpoint address x06 (the bulk PC->Scope channel), but the scope doesn't respond. (That is, I send commands which should have obvious consequences, like "acquire:state on\n" and "acquire:state off\n", but the scope does nothing.) My command-line code for this is:

>>>import usb
>>>metro=usb.busses()
>>>red=metro[4].devices[0]
>>>red.idVendor
1689
>>>red.idProduct
872

#these ID numbers match Tektronix and TDS2014B #respectively, confirming I've reached the scope and not
#my USB printer or a hub.

>>>AgSpring=red.open()
>>>turnstile=red.configurations[0].interfaces[0][0]

#There's only one configuration on the scope, and it has #only one interface.

>>>turnstile.endpoints[0].address
133
>>>turnstile.endpoints[1].address
6
>>>turnstile.endpoints[2].address
135
>>>turnstile.endpoints[1].type
2
>>>usb.ENDPOINT_TYPE_BULK
2
>>>bout=turnstile.endpoints[1]
>>>AgSpring.bulkWrite(bout.address,"acquire:state run\n")
18
>>>AgSpring.claimInterface(turnstile)
>>>AgSpring.bulkWrite(bout.address,"acquire:state run\n")
18
>>>AgSpring.resetEndpoint(bout.address,"acq:state run\n")
18

I don't know if the claimInterface() and resetEndpoint() commands are necessary, but it seems I'm still missing something - I can't even replicate the results from pyVISA.

Do you have better documentation of pyUSB than what's at http://wiki.erazor-zone.de/wiki:projects:python:pyusb:pydoc?do=show#Interface
?

Also, I'm still learning the USB-specification document from http://www.usb.org/developers/docs/
Are there any obvious missteps in the code above?

Thanks.

[SMesser]

okay, the last bit of the code in the above message should've been

>>>AgSpring.resetEndpoint(bout.address)
>>>AgSpring.bulkWrite(bout.address,"acquire:state run\n")

sorry about the typos.

[SMesser]

My mistake: Tektronix _does_ have a firmware upgrade to v. 22.01 available at

http://www2.tek.com/cmswpt/swdetails.lotr?ct=SW&cs=Application&ci=5359&lc=EN&wt=480&wtwi=5359&wtla=EN&wtty=SW&wtsty=Application&wtpt=DETAILS&wtbu=Instruments+Business&wtpl=Value+Scopes+PL&wtcat=tds2000b&wtmd=TDS1001B%2CTDS1002B%2CTDS1012B%2CTDS2002B%2CTDS2004B%2CTDS2012B%2CTDS2014B%2CTDS2022B%2CTDS2024B&wtti=TDS1000B_2000B+FIRMWARE+UPDATE+VIA+TDS1K2KB_TEK

I haven't yet tried this with NI-VISA, but it's supposed to be fully USBTMC compliant.

[magtech]

[back from Christmas holidays, sorry about the long break]

You will want to read the two documents here:
http://www.usb.org/developers/devclass_docs/USBTMC_1_006a.zip

and most of Chapter 9 of the USB2.0 specification.

I used this application as an example of how to communicate using PyUSB: http://scott.weston.id.au/software/pymissile/
It shows how to find the device, etc. Very easy to modify and it should explain the claiming interface part.

This is how you send a message to the scope:

e.g. I define the "device dependent" write and read request message arrays according to the example provided in the USBTMC specification.
        GETID_OUT =     [       DEV_DEP_MSG_OUT,
                                        0x01, 0xFE,
                                        0x00,
                                        0x07, 0x00, 0x00, 0x00,
                                        0x01, 0x00, 0x00, 0x00,
                                        '*',  'i',  'd', 'n',
                                        '?',  0x0d, 0x0a, 0x00 ]
        GETID_IN = [    DEV_DEP_MSG_IN,
                                        0x02, 0xFD,
                                        0x00,
                                        0x00, 0x50, 0x00, 0x00,
                                        0x00, 0x00, 0x00, 0x00 ]

I then send it out to endpoint 6.
self.dev.handle.bulkWrite(6, self.GETID_OUT)

and then I request a read:
self.dev.handle.bulkWrite(6, self.GETID_IN)
data = self.dev.handle.bulkRead(5, 0x64)

and print it out "nicely":
print buffer_to_string(data)


This works only if I use the PyVISA first, so I must be missing some crucial initialisation steps. I have tried to re-recreate the initialisation steps that I see on the USB analyser, but it doesn't work.

Also, this doesn't work 100% of the time when it does start working. Please post any new discoveries!