problem with usbtmc-communication
jeandubois314 at gmail.com
Fri Dec 7 14:46:45 CET 2012
On 6 dec, 21:15, w... at mac.com wrote:
> On Dec 6, 2012, at 2:41 PM, Jean Dubois <jeandubois... at gmail.com> wrote:
> > On 6 dec, 15:50, w... at mac.com wrote:
> >> On Dec 6, 2012, at 8:50 AM, Jean Dubois <jeandubois... at gmail.com> wrote:
> >> [byte]
> >>> It seems there is some misunderstanding here. What I meant with how
> >>> to "do the equivalent in Python" refered to "reading characters
> >>> rather than lines".
> >>> I have written working code myself for another Keithleu which does use
> >>> RS232 for communication. The problem now is specifically for the new
> >>> Keithley which doesn't allow RS232 but only USB-communication over
> >>> usbtmc. So if the "buffer-problem" could be changed by reading
> >>> characters that would be great.
> >>> regards,
> >>> Jean
> >>> --
> >> Sorry about the misunderstanding (and subsequent waste of bandwidth). However, if you will look at the serial reads and writes in that handler, you will see that it does things like "serial.read(n)" where "n" is an explicit number, the number of bytes to be read from the serial buffer.
> >> -Bill
> > I tried changing measurementcurr=usbkeith.readline() to
> > measurementcurr=usbkeith.read(10000)
> > but this leads to trouble with the usbtmc-thing:
> > Measured current 1:
> > Traceback (most recent call last):
> > File "./keith2200rev2.py", line 26, in <module>
> > measurementvolt=usbkeith.read(10000)
> > IOError: [Errno 110] Connection timed out
> > and hereafter I need to restart the Keithley...:-(
> > regards,
> > Jean
> > --
> Several comments:
> 1) I can't be sure, but that would seem to be asking the Keithley to be providing 10,000 readings. I don't know about the GPIB bus (which this USBTMC library seems to be trying >to emulate), but most serial devices expect to provide one answer per read-write handshake. That is, you send one read command and get one answer back. That answer may contain >several bytes, but I'd be surprised it it contained 10,000. The typical cycle is something like send-an-initialize, read-status, send-mode-set-up, read-status, send trigger >command, read-answer… lather and repeat. (Or some logical equivalent of all that). On the assumption that the USBTMC API handles most of that, I'd try usbkeith.read(n) where >"n" is the number of decimal digits you expect to get back plus sign.
10000 wasn't a good guess indeed
> 2) I took a quick look at the Keithley and National Instruments web sites (where the documentation is at best, VERY poorly indexed and hard to search for). USBTMC *appears* to be a software layer designed to allow newer Tektronix and Keithley instruments to be driven using older software that drove GPIB equipment. To make matters worse, if I'm reading it right (I didn't study in detail) it appears to ALSO be providing a GPIB-like API to Windows versions of National Instruments LabView.
> 3) If I understand what you are trying to do, you want to go straight from python to the Keithley USB port, without detouring (USB-to-GPIB and GPIB back to USB).
Yes indeed, that's exactly what I want
> 4) I did find (but did not try to read in detail) the following link: http://www.ni.com/white-paper/4478/en which documents direct USB control of instruments. The python serial >library provides quite transparent control of reading and writing to the USB interface. Maybe following this link will get you going.
Thanks for the link, but as you can see there they want to push NI-
VISA forward as the solution, which under Linux means more complexity
and surely isn't as simple to install as they claim, so if possible
I'd avoid ni-visa.
I'll experiment further Monday with read() and keep you informed
More information about the Python-list