problem with usbtmc-communication

wrw at wrw at
Tue Dec 11 15:34:26 CET 2012

On Dec 11, 2012, at 1:58 AM, Jean Dubois <jeandubois314 at> wrote:

> On 10 dec, 16:34, w... at wrote:
>> On Dec 10, 2012, at 8:31 AM, Jean Dubois <jeandubois... at> wrote:
>> [byte]

>>> 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
>>> thanks,
>>> jean
>>> Here follows the new code:
>>> #!/usr/bin/python
>>> import time
>>> import os
>>> import sys
>>> measurementcurr=''
>>> measurementvolt=''
>>> timesleepdefault=5
>>> print "Enter a numofchar (11 =<numchar =<4095):",
>>> numofchar = int(raw_input())
>>> filename ='mydata.txt'
>>> usbkeith = open('/dev/usbtmc1','r+')
>>> usbkeith.flush()
>>> usbkeith.write("*IDN?\n")
>> It seems like a real leap of faith to be opening /dev/usbtmc1 as though it were a file-oriented device.  I've never heard of ANY instrument interface implemented this way.
>> Where did you see example code that did that.
> I found examples in the usbtmc kernel driver documentation (the
> examples there are given in C):

OK - I see where the examples came from, and I notice -

	int my_inst;

and similarly in another place -


Note that both write commands contain a byte count of the number of characters to be written (\n counts as one character).
Again, the read commands contain byte counts.  I'm very suspicious that a write command with no byte count writes nothing, but does move a buffer pointer.


More information about the Python-list mailing list