problem with usbtmc-communication

[wrw at mac.com]

On Dec 6, 2012, at 2:41 PM, Jean Dubois <jeandubois314 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
>> 
>>> --
>>> http://mail.python.org/mailman/listinfo/python-list
>> 
>> 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
> -- 
> http://mail.python.org/mailman/listinfo/python-list

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.

-------------

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).

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.

-Bill