problem with usbtmc-communication

Jean Dubois jeandubois314 at
Mon Dec 10 14:31:49 CET 2012

On 7 dec, 14:46, Jean Dubois <jeandubois... at> wrote:
> On 6 dec, 21:15, w... at wrote:
> > On Dec 6, 2012, at 2:41 PM, Jean Dubois <jeandubois... at> wrote:
> > > On 6 dec, 15:50, w... at wrote:
> > >> On Dec 6, 2012, at 8:50 AM, Jean Dubois <jeandubois... at> 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 "" 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
> > >
> > > but this leads to trouble with theusbtmc-thing:
> > > Measured current 1:
> > > Traceback (most recent call last):
> > >  File "./", line 26, in <module>
> > >
> > > 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 thisUSBTMClibrary 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 theUSBTMCAPI handles most of that, I'd try 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: 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
> regards,
> Jean
I changed the program as below an experimentally found out I have to
use an number of characters between 11 and 4095
I doesn't seem to make any difference which value I choose in that
interval, however the results are as follows:
0.0077219 0.0295029; this is rubbish
0.0249596 0.261837; this should have been the first data pair
0.0499763 0.516741; this should have been the 2nd data pair
0.0750685 0.767388; this should have been the 3rd data pair
                     4th data pair is missing

As you can see this approach suffers from the same "buffer problem" as
the approach with readline did. One now good argue as a workaround:
get rid of the first data pair and add an extra measure command for
the missing data pair, however this still does not explain why this
problem is there in Python and not in Octave and I also fear I'll get
more trouble when sending combined commands e.g. such as that to
create a staircase current
So my question is, how to modify the Python-code such that the first
data pair is indeed the first data pair


Here follows the new code:
import time
import os
import sys
print "Enter a numofchar (11 =<numchar =<4095):",
numofchar = int(raw_input())
filename ='mydata.txt'
usbkeith = open('/dev/usbtmc1','r+')
#strip blank line:
print 'Found device: ',identification
usbkeith.write("SYST:REM" + "\n")
usbkeith.write(":SENS:VOLT:PROT 1.5\n")
keithdata = open(filename,'w')
usbkeith.write(":OUTP:STAT ON\n")
for number, current_in in enumerate(('0.025', '0.050', '0.075',
'0.100'), 1):
   usbkeith.write(":SOUR:CURR %s\n" % current_in)
   print 'Measured current %d: ' % number, measurementcurr
   print 'Measured voltage %d: ' % number, measurementvolt
   keithdata.write(measurementcurr.strip()+' '+measurementvolt)
usbkeith.write(":OUTP:STAT OFF\n")
print "Goodbye, data logged in file:"
print filename

More information about the Python-list mailing list