On 6 dec, 21:15, w...@mac.com wrote: > On Dec 6, 2012, at 2:41 PM, Jean Dubois <jeandubois...@gmail.com> wrote: > > > > > > > > > > > On 6 dec, 15:50, w...@mac.com wrote: > >> On Dec 6, 2012, at 8:50 AM, Jean Dubois <jeandubois...@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. 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 regards, Jean -- http://mail.python.org/mailman/listinfo/python-list
