Author Topic: Python-based instrument control  (Read 44980 times)

0 Members and 1 Guest are viewing this topic.

Offline hochopeper

  • Supporter
  • ****
  • Posts: 2
Re: Python-based instrument control
« Reply #25 on: March 25, 2014, 12:09:39 pm »
For realtime plots I think the new plotting library being developed mainly by the continuum.io folks ... http://bokeh.pydata.org

Bokeh has client server architecture and realtime plotting appears to be on the agenda for improvements. This should I hope (I've not used it yet) allow the GUI of the plot operate independently of the data acquisition.
 

Offline alex.forencichTopic starter

  • Frequent Contributor
  • **
  • Posts: 397
  • Country: us
    • Alex Forencich
Re: Python-based instrument control
« Reply #26 on: March 26, 2014, 08:20:51 am »
For realtime plots I think the new plotting library being developed mainly by the continuum.io folks ... http://bokeh.pydata.org

Bokeh has client server architecture and realtime plotting appears to be on the agenda for improvements. This should I hope (I've not used it yet) allow the GUI of the plot operate independently of the data acquisition.

That looks like it could be pretty interesting as well.  Unfortunately, it seems the AUR package for Arch Linux is broken, so I have not been able to install it yet. 

I think I'm going to start by taking a look at Kst - it seems to have some sort of real-time capability.  I will look in to writing a basic logging script for my 34401A this week. 
Python-based instrument control: Python IVI, Python VXI-11, Python USBTMC
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: Python-based instrument control
« Reply #27 on: March 27, 2014, 10:09:37 pm »
For realtime plots I think the new plotting library being developed mainly by the continuum.io folks ... http://bokeh.pydata.org

Bokeh has client server architecture and realtime plotting appears to be on the agenda for improvements. This should I hope (I've not used it yet) allow the GUI of the plot operate independently of the data acquisition.

I think I'm going to start by taking a look at Kst - it seems to have some sort of real-time capability.  I will look in to writing a basic logging script for my 34401A this week. 
I'd have to agree on the choice of kst. Bokeh looks sorta cute, but "yes, we are working on improvements for real-time" != "works well in real-time". If you want bokeh-like pretty-plot functionality but significantly more awesome++ (IMO), then it's ggplot2 time. And I noticed that ggplot2 now also works from python, for example through rpy. w00t! So I'll be checking that one for low update rate high quality plots, which just happen to also be highly pdf exportable with zero extra effort. ;) And for high update rate & large amounts of data & real time goodness kst indeed looks promising.

And thank you very much Mr Alex sir, for python-ivi and python-vxi11.  :-+ Today I received my DSA815-TG, and got it python scripted in < 30 mins from T_out_of_box. :) I also made a little script based on your python-vxi11 that automates  rikey_dsa calls, so execute script ==> install the 10 Hz RBW license (*). :)

(*) Or any of the other licenses you care for. I just used the 10 Hz RBW license to test the procedure. Worked in one go! Well, two goes. Had to remove the minus characters from the license key that rikey_dsa spits out.

So far I like python-vxi11, and will use it in future scripts. Haven't really used the ivi side of it yet. I'll probably try to extend some random class for use with the DSA815-TG, and see how that goes. Oh yeah, one thing I noticed: the timeouts are hardcoded? Or did I miss the magic method?
 

Offline alex.forencichTopic starter

  • Frequent Contributor
  • **
  • Posts: 397
  • Country: us
    • Alex Forencich
Re: Python-based instrument control
« Reply #28 on: March 28, 2014, 03:19:27 am »
I'd have to agree on the choice of kst. Bokeh looks sorta cute, but "yes, we are working on improvements for real-time" != "works well in real-time". If you want bokeh-like pretty-plot functionality but significantly more awesome++ (IMO), then it's ggplot2 time. And I noticed that ggplot2 now also works from python, for example through rpy. w00t! So I'll be checking that one for low update rate high quality plots, which just happen to also be highly pdf exportable with zero extra effort. ;) And for high update rate & large amounts of data & real time goodness kst indeed looks promising.

And thank you very much Mr Alex sir, for python-ivi and python-vxi11.  :-+ Today I received my DSA815-TG, and got it python scripted in < 30 mins from T_out_of_box. :) I also made a little script based on your python-vxi11 that automates  rikey_dsa calls, so execute script ==> install the 10 Hz RBW license (*). :)

(*) Or any of the other licenses you care for. I just used the 10 Hz RBW license to test the procedure. Worked in one go! Well, two goes. Had to remove the minus characters from the license key that rikey_dsa spits out.

So far I like python-vxi11, and will use it in future scripts. Haven't really used the ivi side of it yet. I'll probably try to extend some random class for use with the DSA815-TG, and see how that goes. Oh yeah, one thing I noticed: the timeouts are hardcoded? Or did I miss the magic method?

Kst does look pretty good, I have been using it to look at a couple of scope traces that I saved in csv format and it appears to work quite nicely.  I have not had a chance to try out real-time plotting yet, though. 

If you want to work on a python-ivi driver for the Rigol DSA units, that would be excellent.  Actually, the spectrum analyzer base class is not completely finished at the moment, not much more than the base class is implemented.  The basic functionality is covered, though.  Finishing that off is on my to-do list.  Also, the IVI spectrum analyzer spec doesn't include tracking generators, so I will have to find a way to add that functionality in somehow.  I have an HP 8595E with a tracking generator that I would like to support completely.  I would suggest working off of the Agilent 8590E driver.  You may just need to substitute the proper commands from the Rigol programmer's manual to get most of it working. 

In terms of setting timeouts, that is certainly possible.  If you're using vxi11 directly, then you can just set instr.timeout to what you need.  Right now the units are in ms, but I suppose that could be changed to seconds.  If you're using vxi11 through python-ivi, the vxi11 instance will be called _interface so you can just set instr._interface.timeout to what you need. 
Python-based instrument control: Python IVI, Python VXI-11, Python USBTMC
 

Offline alex.forencichTopic starter

  • Frequent Contributor
  • **
  • Posts: 397
  • Country: us
    • Alex Forencich
Re: Python-based instrument control
« Reply #29 on: March 31, 2014, 08:27:22 am »
Alright, here is some example logging code for use with Kst.  There are a few variables at the top - file_name, sample_period, and sample_count - as well as the call to Python IVI to connect to the instrument.  Configure these as necessary.  This script does not actually configure the instrument for whatever measurement you need; all it does is read samples from a multimeter.  So you can either configure the meter manually before starting the script, or you can add code after the ivi call to set up the measurement.  The samples (along with a timestamp) are written to a csv file.  Before starting, the script also writes out an xml file for Kst.  Now, the XML file that it writes is a bit hacked together, I just saved one out of Kst and hen stripped out a bunch of stuff, so it might not be terribly ideal.  But it worked for the limited testing I have done so far.  To use this thing, start the script in python, then open up the generated .kst file in Kst.  As the data is collected, Kst will automatically load and display the new data points.  The script will stop automatically after collecting the specified number of samples.  It should also stp if there is an error communicating with the instrument, or if the script is interrupted with ctrl c. 

The timing loop is set up so that the script attempts to 'make up for lost time' if there is a mis-timed sample somewhere.  However, I am not sure if the time calls will have the same resolution on all platforms. 

Code: [Select]
import ivi
import time

dmm = ivi.agilent.agilent34401A("TCPIP::192.168.1.105::gpib,22::INSTR")

file_name = 'log'

sample_period = 2.0
sample_count = 100

fp = open(file_name '.csv', 'w')

kp = open(file_name '.kst', 'w')

kp.write("""<?xml version="1.0" encoding="UTF-8"?>
<kst version="2.0">
    <data>
        <source reader="ASCII file" file="{0}.csv">
            <properties vector="INDEX" interpretation="1" delimiters="#" columntype="2" columndelimiter="," headerstart="1" fields="0" readfields="true" usedot="true" columnwidthisconst="false" readunits="false" units="0" limitFileBuffer="false" limitFileBufferSize="0" useThreads="0" asciiTimeFormat="hh:mm:ss.zzz" dataRate="1" offsetDateTime="false" offsetFileDate="false" offsetRelavive="true" dateTimeOffset="2014-03-24T22:16:59" relativeOffset="0"/>
        </source>
    </data>
    <variables>
        <datavector file="{0}.csv" field="time" start="0" count="15985" skip="-1" doAve="false" startUnits="" rangeUnits="" initialVNum="1" initialXNum="25"/>
        <datavector file="{0}.csv" field="sample" start="0" count="15985" skip="-1" doAve="false" startUnits="" rangeUnits="" initialVNum="2" initialXNum="37"/>
    </variables>
    <objects/>
    <relations>
        <curve xvector="time (V1)" yvector="sample (V2)" color="#0000ff" headcolor="#008000" barfillcolor="#000000" haslines="true" linewidth="0" linestyle="0" haspoints="false" pointtype="3" pointdensity="0" pointsize="12" hasbars="false" ignoreautoscale="false" hashead="false" headtype="0" initialCNum="1"/>
    </relations>
    <graphics>
        <view name="View &amp;1" width="1470" height="633" color="#ffffff" style="1">
            <plot tiedxzoom="false" tiedyzoom="false" leftlabelvisible="true" bottomlabelvisible="true" rightlabelvisible="true" toplabelvisible="true" globalfont="Sans,10,-1,5,50,0,0,0,0,0" globalfontscale="16" globalfontcolor="#000000" showlegend="true" hidebottomaxislabel="false" hidetopaxislabel="false" hideleftaxislabel="false" hiderightaxislabel="false" numberaxislabelscale="true" initialPlotNum="1" name="Plot">
                <relativesize width="1" height="1" centerx="0.5" centery="0.5" posx="0" posy="0" leftx="0" lefty="1" rightx="1" righty="1" fixaspect="false" lockpostodata="false"/>
                <cartesianrender name="Cartesian Plot" type="1">
                    <relation tag="sample vs time (C1)"/>
                </cartesianrender>
            </plot>
        </view>
    </graphics>
</kst>""".format(file_name))

kp.close()

fp.write("time, sample\n")

target_time = time.time()   sample_period

for sample in range(sample_count):
    last_sample_time = time.time()
    sample_value = dmm.measurement.read(1)
    print(sample_value)
   
    fp.write("%f, %g\n" % (last_sample_time, sample_value))
    fp.flush()
   
    offset = target_time - time.time()
   
    if offset > 0:
        time.sleep(offset)
   
    target_time  = sample_period
   
Python-based instrument control: Python IVI, Python VXI-11, Python USBTMC
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: Python-based instrument control
« Reply #30 on: April 01, 2014, 02:36:34 am »
I've been mucking about with kst a bit as well. Getting a simple plot working was totally trivial, but for things like a DataMatrix I find the available documentation and examples frustratingly lacking in detail. I hope I am just blind and unable to find the right docs. But what I could find (KstBook.pdf or some such) does not do the trick for me. "Use this incomplete example and it will work". Yes, except for all the other instances and 45987 permutations of those instances where it doesn't. "You can use xml files." Oh cool! Any docs on that? "Docs? What now?"

Do you happen to have an example of a datasource (defined in xml or kstscript or whatever) using an ascii file for the matrix data. Or at this point, anything that works at all? :P

Like I said, simple plot, too easy. Datasource + datamatrix according to the docs ... nope.
Mostly I am confuzled by the "[MATRIX,size-or-something,0,0,1,1]" part of it. That I can understand reading the docs. Except that it doesn't work as advertised.

Oh another thing that maybe you know ... is there any way to "overwrite" old datapoints in real time? To get a sort of oscilloscope display as it were. I suppose you could do that by just resetting the data + refreshing the plot, but that seems a bit lame.

At the moment I can get a spectral waterfall plot with a static matrix as data. I can also grab the spectrum from the DSA815. Oh if only certain documentation didn't suck so bad, then I could do a waterfall plot from the DSA815 in real-time. Grrrrr.

I'll get back to it later, but for now I am fed up with this.
 

Offline alex.forencichTopic starter

  • Frequent Contributor
  • **
  • Posts: 397
  • Country: us
    • Alex Forencich
Re: Python-based instrument control
« Reply #31 on: April 01, 2014, 03:40:07 am »
I have not looked at any Kst documentation so far, actually.  All I did was put together something decent in the Kst GUI, then I saved the xml file and played around with it.  But I wasn't trying to do anything more complicated than a single curve of one variable, so this might not be the best strategy for everyone. 

It's not surprising the documentatio is bad, that tends to happen a lot with open source projects.  For Pyton IVI,  am trying to mitigate this issue to some extent by merging the documentation with the code as much as possible, but it remains to be seen how well this will work.  And this is certainly not the best solution for every project. 

I would suggest trying to save an XML file from Kst, and then playing around with that file and reloading it.  It may be faster to figure out how the application works by actually running it than from looking at outdated and/or incomplete documentaion. 
Python-based instrument control: Python IVI, Python VXI-11, Python USBTMC
 

Offline Noise Floor

  • Regular Contributor
  • *
  • Posts: 117
  • Country: us
Re: Python-based instrument control
« Reply #32 on: May 22, 2014, 01:31:24 am »
I've been mucking about with kst a bit as well. Getting a simple plot working was totally trivial, but for things like a DataMatrix I find the available documentation and examples frustratingly lacking in detail. I hope I am just blind and unable to find the right docs. But what I could find (KstBook.pdf or some such) does not do the trick for me. "Use this incomplete example and it will work". Yes, except for all the other instances and 45987 permutations of those instances where it doesn't. "You can use xml files." Oh cool! Any docs on that? "Docs? What now?"

I too have been playing with Kst and have the same complaint.  However this is par for the course for projects like this, if it catches on, documentation will eventually improve.

Alex F., any thought on starting a GitHub project around this? 
 

Offline alex.forencichTopic starter

  • Frequent Contributor
  • **
  • Posts: 397
  • Country: us
    • Alex Forencich
Re: Python-based instrument control
« Reply #33 on: May 22, 2014, 01:54:25 am »
I've been mucking about with kst a bit as well. Getting a simple plot working was totally trivial, but for things like a DataMatrix I find the available documentation and examples frustratingly lacking in detail. I hope I am just blind and unable to find the right docs. But what I could find (KstBook.pdf or some such) does not do the trick for me. "Use this incomplete example and it will work". Yes, except for all the other instances and 45987 permutations of those instances where it doesn't. "You can use xml files." Oh cool! Any docs on that? "Docs? What now?"

I too have been playing with Kst and have the same complaint.  However this is par for the course for projects like this, if it catches on, documentation will eventually improve.

Alex F., any thought on starting a GitHub project around this?

Around what?  Scripts for writing out Kst files?  General python-based data logging?  Combination of the two?  Give me a nice projct name and I'll throw up a repo. 

Unfortunately, my time has been almost completely devoted to a few other projects the past few weeks (fyi: the Altera reference design for PCIe gen 3 SUCKS, I found 3 different bugs in it already  |O), and they Python instrument control stuff is currently on the back burner. 
Python-based instrument control: Python IVI, Python VXI-11, Python USBTMC
 

Offline Noise Floor

  • Regular Contributor
  • *
  • Posts: 117
  • Country: us
Re: Python-based instrument control
« Reply #34 on: May 22, 2014, 02:40:59 am »
I've been mucking about with kst a bit as well. Getting a simple plot working was totally trivial, but for things like a DataMatrix I find the available documentation and examples frustratingly lacking in detail. I hope I am just blind and unable to find the right docs. But what I could find (KstBook.pdf or some such) does not do the trick for me. "Use this incomplete example and it will work". Yes, except for all the other instances and 45987 permutations of those instances where it doesn't. "You can use xml files." Oh cool! Any docs on that? "Docs? What now?"

I too have been playing with Kst and have the same complaint.  However this is par for the course for projects like this, if it catches on, documentation will eventually improve.

Alex F., any thought on starting a GitHub project around this?

Around what?  Scripts for writing out Kst files?  General python-based data logging?  Combination of the two?  Give me a nice projct name and I'll throw up a repo. 

Unfortunately, my time has been almost completely devoted to a few other projects the past few weeks (fyi: the Altera reference design for PCIe gen 3 SUCKS, I found 3 different bugs in it already  |O), and they Python instrument control stuff is currently on the back burner.

Ignore my comment, I now noticed your signature.   |O

I hear you on having to many projects, this falls in the "nice to do" category.
 

Offline alex.forencichTopic starter

  • Frequent Contributor
  • **
  • Posts: 397
  • Country: us
    • Alex Forencich
Re: Python-based instrument control
« Reply #35 on: May 22, 2014, 03:14:40 am »

Ignore my comment, I now noticed your signature.   |O

I hear you on having to many projects, this falls in the "nice to do" category.

No worries.  Actually, the instrument control stuff is something that we're looking in to using for taking some measurements on some experimental photonic switching chips (we have two different ones we're hoping to work with soon, one MEMS based and one silicon photonics based).  Taking measurements of these switches requires coordinating not only the signal sources, sinks, and routing, but also changing the switch configuration itself, so it's a pretty complicated interfacing issue.  The idea is to use Python to control the test equipment as well as an FPGA to drive the DUT.  So even if it's on the back burner for the moment, it's going to pick up again once we're gearing up to test one of the switches. 
Python-based instrument control: Python IVI, Python VXI-11, Python USBTMC
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: Python-based instrument control
« Reply #36 on: May 20, 2015, 07:28:44 am »
Waking up this thread.

So in: https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg675845/#msg675845
Bingo found this link for the DS1000z series to perform a screen capture.

Python screendump for windows via LXI (TCP/IP)
https://hackaday.io/project/5807-driverless-rigol-ds1054z-screen-capture-over-lan

I did try it on my DS2000 scope but I guess it doesn't have telnet capabilities. So I did stumble on alex.forencich's vxi11 and I substitute it and I was able to do the capture on my DS2000, but it took 2 minutes and 40 seconds per capture.

https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg676102/#msg676102

So I used wireshark to check what is going on, and for some reason it doesn't like to read large packets and I did modified the script again so it wouldn't go past the MTU size of 1514 bytes and:

Quote
C:\Users\Miguel\Downloads\Rigol>python OscScreenGrabLAN.py

Usage:
    OscScreenGrabLAN.py

This program capture the image displayed
    by a Rigol DS2000 series oscilloscope, then save it on the computer
    as a PNG file with a timestamp in the file name.

    The program is using LXI protocol, so the computer
    must have LAN connection with the oscilloscope.
    USB and/or GPIB connections are not used by this software.

    No VISA, IVI or Rigol drivers are needed.

Instrument ID:
RIGOL TECHNOLOGIES,DS2302,DS2A$$$$$$$$,00.03.03.SP1 (blanked my serial number for the paste)
Receiving: [##########] 100%
Read took 3 seconds
Saved file: DS2302_2015-05-20_01.54.15.png

And it took just 4 seconds (I know it says 3 but a wireshark capture shows it was 3.98 seconds).

So here is the newest version of the script:
Code: [Select]
__author__ = 'RoGeorge'
#
# Modified to work with DS2000 by miguelvp
# using vxi11 by Alex Forencich and Michael Walle
# [url]https://github.com/alexforencich/python-vxi11[/url]
#
import vxi11
import time
import sys
import os
import Image
import StringIO
from datetime import datetime

# Update the next lines for your own default settings:
path_to_save = ""
IP_DS2000 = "192.168.1.6"

expected_len = 1152067
TMC_header_len = 11
terminator_len = 2

company = 0
model = 1
serial = 2

# Check parameters
script_name = os.path.basename(sys.argv[0])

# Print usage
print
print "Usage:"
print "    " + script_name
print
print "This program capture the image displayed"
print "    by a Rigol DS2000 series oscilloscope, then save it on the computer"
print "    as a PNG file with a timestamp in the file name."
print
print "    The program is using LXI protocol, so the computer"
print "    must have LAN connection with the oscilloscope."
print "    USB and/or GPIB connections are not used by this software."
print
print "    No VISA, IVI or Rigol drivers are needed."
print

# Create/check if 'path' exists

# Check network response (ping)
response = os.system("ping -n 1 -w 20 " + IP_DS2000 + " > nul")
if response != 0:
print
print "No response pinging " + IP_DS2000
print "Check network cables and settings."
print "You should be able to ping the oscilloscope."
sys.exit("ERROR")

# Open a VXI11 session
instr =  vxi11.Instrument(IP_DS2000)
instrument_id = instr.ask("*IDN?")

# Check if instrument is set to accept LAN commands
if instrument_id == "command error":
print instrument_id
print "Check the oscilloscope settings."
print "Utility -> IO Setting -> LAN Set"
sys.exit("ERROR")

# Check if instrument is indeed a Rigol DS2000 series
id_fields = instrument_id.split(",")
if (id_fields[company] != "RIGOL TECHNOLOGIES") or \
(id_fields[model][:3] != "DS2"):
print
print "ERROR: No Rigol from series DS2000 found at ", IP_DS2000
sys.exit("ERROR")

print "Instrument ID:"
print instrument_id

# Prepare filename as C:\MODEL_YYYY-MM-DD_HH.MM.SS
timestamp = time.strftime("%Y-%m-%d_%H.%M.%S", time.localtime())
filename = path_to_save + id_fields[model] + "_" + timestamp

# Ask for an oscilloscope display print screen
instr.write_raw("display:data?")

# Time transfer duration
starttime = datetime.now()

# Get TMC Header
buff = instr.read_raw(TMC_header_len)
# Initialize previous progress so we only update on changes
previous_progress = -1;
# Read only 1420 bytes at a time until done, a bigger amount stalls the rpc and makes the transfer slow
while len(buff) < expected_len:
tmp = instr.read_raw(1420)
if len(tmp) == 0:
break
buff += tmp
# Compute and print progress bar
progress =  100 - (expected_len - len(buff))*100/expected_len
if (previous_progress != progress):
sys.stdout.write('\rReceiving: [{0}] {1}%'.format('#'*(progress/10)+' '*(10-progress/10), progress))
sys.stdout.flush()
previous_progress = progress

# Print delta time in seconds
currenttime = datetime.now()
delta = currenttime - starttime
print
print "Read took", delta.seconds, "seconds"

# Strip TMC Blockheader and terminator bytes
buff = buff[TMC_header_len:-terminator_len]

# Save as PNG
im = Image.open(StringIO.StringIO(buff))
im.save(filename + ".png", "PNG")
print "Saved file:", filename + ".png"

# Save as BMP
# scr_file = open(filename + ".bmp", "wb")
# scr_file.write(buff)
# scr_file.close()
# print "Saved file:", filename + ".bmp"

# Close Instrument
instr.close()

It has a progress bar and all :)

So it's 40 times faster than the 160 seconds it was taking before and it's even faster than saving it to a thumb drive!  :scared:

Thank you Alex for providing this :-+

If you notice I did change the raw read to 1420 at a time instead of:

Code: [Select]
buff = instr.ask_raw("display:data?", expected_len)

So I decided to change vxi11.py open from:
Code: [Select]
        self.max_recv_size = min(max_recv_size, 1073741824)

to:
Code: [Select]
        self.max_recv_size = min(max_recv_size, 1420)

and I can revert back the code and achieve the same speed, but I do like the progress bar so I think I'll keep mine like it is and changed the size in both places.

Since you support other protocols other than VXI-11 over TCP I guess I'll leave it up to you to do the change to have the right MTU per protocol, but for TCPIP it seems 1420 is the best, if I use 1421 it causes extra TCP continuation packets and it stalls the transfer but with 1420 it's just perfect!

Wireshark happy:


Capture PNG:


Thank you again alex.forencich!!
« Last Edit: May 20, 2015, 07:34:54 am by miguelvp »
 

Offline alex.forencichTopic starter

  • Frequent Contributor
  • **
  • Posts: 397
  • Country: us
    • Alex Forencich
Re: Python-based instrument control
« Reply #37 on: May 20, 2015, 07:34:28 am »
Nice work!  Is there any issue with just doing instr.max_recv_size = 1420 and then using the standard read call?

Edit: never mind, I just looked at the code for python-vxi11.  I wonder if I need to add a max_block_size parameter so that this will be done automatically in read_raw.  Also, are you sure the screenshots are always exactly the same size?
« Last Edit: May 20, 2015, 07:39:36 am by alex.forencich »
Python-based instrument control: Python IVI, Python VXI-11, Python USBTMC
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: Python-based instrument control
« Reply #38 on: May 20, 2015, 07:48:28 am »
As for the screenshots, on the ds2000 they are always the same:



But on the DS1000Z it seems it has an extra byte at the end.

I didn't try the instr.max_recv_size = 1420 I guess that would work too, I just found your python project yesterday so I didn't dig that much into it :)


Edit: I guess I could just parse the blockheader and figure out the size of what to read.
« Last Edit: May 20, 2015, 07:53:32 am by miguelvp »
 

Offline alex.forencichTopic starter

  • Frequent Contributor
  • **
  • Posts: 397
  • Country: us
    • Alex Forencich
Re: Python-based instrument control
« Reply #39 on: May 20, 2015, 08:00:59 am »
There is actually some code to do that in python-ivi, see read_ieee_block.  It deals with parsing the header correctly and then reading out the correct number of bytes.  However, it does try to read it all in one shot, so it seems that an additional parameter to specify the maximum read size would be a good idea. 
Python-based instrument control: Python IVI, Python VXI-11, Python USBTMC
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: Python-based instrument control
« Reply #40 on: May 20, 2015, 08:07:14 am »
That's awesome, thanks.

One question, why are the timeouts set to 10 seconds? I did change them locally to 1 second and it works fine.

_timeout & _lock_timeout
 

Offline alex.forencichTopic starter

  • Frequent Contributor
  • **
  • Posts: 397
  • Country: us
    • Alex Forencich
Re: Python-based instrument control
« Reply #41 on: May 20, 2015, 08:13:28 am »
Actually, the timeouts should probably be extended quite a bit.  I have to remember to change the timeout setting to a minute or so when yanking screenshots from a few older instruments (namely my 8593E SA) through my GPIB to LAN box.  The default right now was just something that seemed reasonable at the time.  I would say that it's probably a better idea to extend those timeouts as much as is reasonable as it's better to have to wait a while for a timeout than to get a timeout during a large transfer.  With something like python-ivi, this could even be changed at run time for specific commands.  This is a major issue with the USBTMC side of things as getting a timeout during a transfer usually requires rebooting the instrument to recover. 
Python-based instrument control: Python IVI, Python VXI-11, Python USBTMC
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: Python-based instrument control
« Reply #42 on: May 20, 2015, 09:12:36 am »
Maybe the high timeouts are needed due to the overhead of using large read sizes.

Didn't look at the code and it's late, but splitting the reads to smaller sub chunks will require smaller timeouts, right?
 

Offline gmb42

  • Frequent Contributor
  • **
  • Posts: 294
  • Country: gb
Re: Python-based instrument control
« Reply #43 on: May 20, 2015, 11:20:14 am »
FWIW, to anonymise Wireshark captures have a look at TraceWrangler.
 

Offline alex.forencichTopic starter

  • Frequent Contributor
  • **
  • Posts: 397
  • Country: us
    • Alex Forencich
Re: Python-based instrument control
« Reply #44 on: May 20, 2015, 03:56:45 pm »
It should never timeout during normal operation. 
Python-based instrument control: Python IVI, Python VXI-11, Python USBTMC
 

Offline VintageNut

  • Frequent Contributor
  • **
  • Posts: 534
  • Country: 00
Re: Python-based instrument control
« Reply #45 on: May 20, 2015, 07:00:44 pm »
I have written short demo python programs for Keithley 2230-30-1 power supply, Keithley 236 and 237 SMUs for transistor curve tracing and Keithley 3706A with 3720 switch card. These were all efforts to get a particular instrument behavior characterized and/or take readings.

I have a Keithley model 7001 on the way that will receive the python treatment for nanovolt measurements.
« Last Edit: May 20, 2015, 07:02:38 pm by VintageNut »
working instruments :Keithley 260,261,2750,7708, 2000 (calibrated), 2015, 236, 237, 238, 147, 220,  Rigol DG1032  PAR Model 128 Lock-In amplifier, Fluke 332A, Gen Res 4107 KVD, 4107D KVD, Fluke 731B X2 (calibrated), Fluke 5450A (calibrated)
 
The following users thanked this post: smoothVTer

Online bingo600

  • Super Contributor
  • ***
  • Posts: 1976
  • Country: dk
Re: Python-based instrument control
« Reply #46 on: May 20, 2015, 08:57:06 pm »
Waking up this thread.

...
...
...

Thank you again alex.forencich!!

Great find  :-+ :-+ (debugging)

Now i'll have to install VXI-11 , also because i know Alex might have improved the linux-gpib support

/Bingo
 

Offline eas

  • Frequent Contributor
  • **
  • Posts: 601
  • Country: us
    • Tech Obsessed
Re: Python-based instrument control
« Reply #47 on: July 24, 2015, 09:37:18 pm »
I have written short demo python programs for Keithley 2230-30-1 power supply, Keithley 236 and 237 SMUs for transistor curve tracing and Keithley 3706A with 3720 switch card. These were all efforts to get a particular instrument behavior characterized and/or take readings.

I have a Keithley model 7001 on the way that will receive the python treatment for nanovolt measurements.

Did you create IVI instrument drivers for any of these?  If so, do you mind sharing them somewhere? I have started working with some K2000 and K2700 DMMs and would like to see how much can be reused, particularly for switch control. Right now I'm just issuing SCPI commands over VXI-11 (I'm using an ICS 8065).
 

Offline VintageNut

  • Frequent Contributor
  • **
  • Posts: 534
  • Country: 00
Re: Python-based instrument control
« Reply #48 on: July 25, 2015, 07:09:00 pm »
I did not create any driver(s). I just send SCPI commands via PyVisa which is via NI Visa. I use Python 2.7
working instruments :Keithley 260,261,2750,7708, 2000 (calibrated), 2015, 236, 237, 238, 147, 220,  Rigol DG1032  PAR Model 128 Lock-In amplifier, Fluke 332A, Gen Res 4107 KVD, 4107D KVD, Fluke 731B X2 (calibrated), Fluke 5450A (calibrated)
 

Offline eas

  • Frequent Contributor
  • **
  • Posts: 601
  • Country: us
    • Tech Obsessed
Re: Python-based instrument control
« Reply #49 on: July 26, 2015, 07:03:54 am »
Thanks for the clarification.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf