Python-based instrument control

[alex.forencich]

There seems to be a growing interest on the forum in terms of cross-platform, extensible instrument control that isn't tied to a specific vendor.  I have been working for some time on a collection of Python scripts that make up a cross-platform instrument control solution called Python IVI. 

http://github.com/alexforencich/python-ivi

The idea is to create an abstraction layer that makes using various instruments straightforward, based on the IVI standard.  Python IVI can then leverage Python VXI11, Python USBTMC, PySerial, and Linux GPIB to communicate with instruments.  Python VXI11 is a pure Python VXI11 driver for LAN based instruments while Python USBTMC leverages PyUSB for instruments that support USBTMC.  Everything except Linux GPIB support is cross-platform and has been tested in Linux, Windows, and Mac OS.  Python IVI is also written so that it will work correctly in both Python 2 and Python 3. 

Python IVI is desgined so that it is easy to extend its functionality either with additional instrument control protocols (say, serial to GPIB devices like the Prologix units) or additional instruments. 

Currently, Python IVI supports a number of different instrument families - Agilent Infiniivision and Infiniium oscilloscopes, Agilent and Tektronix programmable power supplies, HP spectrum analyzers, Tektronix AWGs, and a number of other odds and ends.  Things like waveform and screenshot readout are supported for most instruments. 

I would love for Python IVI to support a wide range of instruments, especially Rigol oscilloscopes.  Unfortunately, I cannot write drivers for instruments that I do not have access to, so I would like to call upon anyone who is interested in extensible instrument control to lend a hand. 

If anyone here finds Python IVI useful and wishes to contribute, I would me more than happy to include your changes in Python IVI so that it can become an even more useful tool. 

[fake-name]

I use python a lot, and have access to both a DS4000 and DS1000Z oscilloscope.

If I get a chance, I'll have a poke around. This is a cool project!

[wiss]

Just got my gpib-card last week and started to play around a bit with python, I'll check this out!

[alex.forencich]

Just got my gpib-card last week and started to play around a bit with python, I'll check this out!

Nice!  I presume you got a PCI GPIB card, then?  What operating system are you using?  If you're running linux, then Python IVI has support for using the linux-gpib python wrapper.  I'm not sure what will work for windows, though.  You may need to install the NI software and PyVISA.  It's probably about time for me to add support for PyVISA to Python IVI to support that sort of setup. 

[psycho0815]

looks not bad. i'll have a look at the documentation on how to write drivers. If it's not too much hassle, i might see what i can do about drivers for the rigol ds1052e and dg1022.

[wiss]

Just got my gpib-card last week and started to play around a bit with python, I'll check this out!

Nice!  I presume you got a PCI GPIB card, then?  What operating system are you using?  If you're running linux, then Python IVI has support for using the linux-gpib python wrapper.  I'm not sure what will work for windows, though.  You may need to install the NI software and PyVISA.  It's probably about time for me to add support for PyVISA to Python IVI to support that sort of setup.

Yup, Gentoo-Linux, no labview, I have only been talking to my multimeters but I do have a HP oscope, Philips counter and HP generator also.

Are there any friendly GUI-widgets for like trend-plots and stuff somewhere?
I'm using the matplotlib window now.

[alex.forencich]

I use python a lot, and have access to both a DS4000 and DS1000Z oscilloscope.

If I get a chance, I'll have a poke around. This is a cool project!

I use python a lot, and have access to both a DS4000 and DS1000Z oscilloscope.

If I get a chance, I'll have a poke around. This is a cool project!

Writing drivers is not all that complicated.  The hard part is just the sheer number of commands that each instrument supports.  There is some documentation included with Python IVI that describes how to create a new driver. 

If you want to write some drivers for Python IVI, you should fork the repo and commit your changes to that, then send me a pull request. 

If you have any questions, feel free to ask by posting here or posting on the Python IVI google group. 

[alex.forencich]

Yup, Gentoo-Linux, no labview, I have only been talking to my multimeters but I do have a HP oscope, Philips counter and HP generator also.

Are there any friendly GUI-widgets for like trend-plots and stuff somewhere?
I'm using the matplotlib window now.

Well, there might not be drivers yet for all of your equipment, but feel free to contribute if you have the time because I'm sure they will be useful to someone else. 

Right now Python IVI is just an abstraction layer that tries to provide common interfaces to similar instruments (e.g. for any scope, you should be able to do scope.channels[0].measurement.fetch_waveform() to read out the waveform data).  There is no explicit support for graphing and logging, but these are rather simple operations to implement in python, especially if you want to do something more complicated (e.g. multiple instruments, conditional logging, etc.).  Unfortunately I can't point you to anything other than matplotlib for plotting.  Generally what I do is dump a csv file (or similar) and then process that separately, either in Excel/OpenOffice/LibreOffice or with another python script.  No sense in a bug in the graphing portion of the script nixing the data before it's saved on disk. 

[wiss]

Well, there might not be drivers yet for all of your equipment, but feel free to contribute if you have the time because I'm sure they will be useful to someone else. 

I guess that implementing the DMM-class will be the start

Right now Python IVI is just an abstraction layer that tries to provide common interfaces to similar instruments (e.g. for any scope, you should be able to do scope.channels[0].measurement.fetch_waveform() to read out the waveform data).  There is no explicit support for graphing and logging, but these are rather simple operations to implement in python, especially if you want to do something more complicated (e.g. multiple instruments, conditional logging, etc.).  Unfortunately I can't point you to anything other than matplotlib for plotting.  Generally what I do is dump a csv file (or similar) and then process that separately, either in Excel/OpenOffice/LibreOffice or with another python script.  No sense in a bug in the graphing portion of the script nixing the data before it's saved on disk.

I'm very fond of the trend-plot on the 34461, which I do not have at home, seems like "trivial" to implement using PC/gpib. That I do not intend for saving data but rather real time viewing.

[alex.forencich]

I guess that implementing the DMM-class will be the start

Which DMM are you using?

I'm very fond of the trend-plot on the 34461, which I do not have at home, seems like "trivial" to implement using PC/gpib. That I do not intend for saving data but rather real time viewing.

Yeah, it should be pretty easy to implement.  I have been mulling over a few GUI type extensions as well, but I do not think they belong in Python IVI directly.  A separate package that imports Python IVI, sure.

One thing that would be really nice is an offline scope trace viewer that supports all of the standard measurements, cursors, zooming, scaling, etc. as well as processing plugins for DSP filtering, serial decoding, clock recovery, line code removal for 8b/10b and 64b/66b, high level decoding (ethernet frames, etc.), single trace eye diagram generation, etc.  The sort of stuff the Infiniium scopes can do (especially if you pay $$$$ for the decoding plugins), but with more flexibility and extensibility.  It could even capture data in more-or-less realtime from a scope (or multiple scopes, even) with Python IVI as a back-end, as a step up from using VNC.  That sort of thing would definitely be enough for a separate project.  I think the sigrok project may do some of this, but I have not looked at that project in some time. 

[wiss]

I guess that implementing the DMM-class will be the start

Which DMM are you using?

Prema 6001 and Keithley 192

I'm very fond of the trend-plot on the 34461, which I do not have at home, seems like "trivial" to implement using PC/gpib. That I do not intend for saving data but rather real time viewing.

Yeah, it should be pretty easy to implement.  I have been mulling over a few GUI type extensions as well, but I do not think they belong in Python IVI directly.  A separate package that imports Python IVI, sure.

Yes, like a labview widget thingie library.

[wiss]

I guess that implementing the DMM-class will be the start

Which DMM are you using?

Prema 6001 and Keithley 192

It looks like the linux-gpib is written for SCPI-instruments, that have the ask concept, neither of my multimeters do it that way. Maybe there should be a linux-gpib-scpi class?

To read something from the prema I send "VDR3L1PFS0" and when doing a read I get "+1.000001E+1VDR3A0T4S0Q0MOP0D0B0" back, as far as I understand from the manual that is the only way to communicate and don't really fit the "ask"-model.

[alex.forencich]

It looks like the linux-gpib is written for SCPI-instruments, that have the ask concept, neither of my multimeters do it that way. Maybe there should be a linux-gpib-scpi class?

To read something from the prema I send "VDR3L1PFS0" and when doing a read I get "+1.000001E+1VDR3A0T4S0Q0MOP0D0B0" back, as far as I understand from the manual that is the only way to communicate and don't really fit the "ask"-model.

Well, what is missing?  As far as I understand it, the basic operations on the bus are 'read' and 'write', while 'ask ' is just a shortcut that calls 'write' and then 'read'.  This is how the VXI-11 and USBTMC fdrivers work, anyway, and they're supposed to be equivalent to GPIB.  You can also read just a specific number of characters, if reading more than that causes problems.  It looks like when you read, you get a measurement, plus a bunch of status information.  I imagine you get a similar string if you read without issuing a write call first.  I think you're going to have to do a bit of creative parsing to get all of the status information organized, but I don't think a rewrite of the underlying library is required.  Take a peek at the power meter drivers in Python IVI, agilent436A and agilent437B.  They aren't terribly complete, but they have a very non-SCPI like interface. 

[zapta]

I have been working for some time on a collection of Python scripts that make up a cross-platform instrument control solution called Python IVI. 

http://github.com/alexforencich/python-ivi

Do you have screenshots?

I am designing a simple battery current monitor and  possibly Python IVI can provide the realtime display and gui.

[alex.forencich]

Python IVI is only an interface layer, there is no GUI component to it. You could use python IVI to read data from your instruments and then use matplotlib or similar to graph the data. I am not sure what the best real-time plotting solution would be, unfortunately.

[wiss]

It looks like the linux-gpib is written for SCPI-instruments, that have the ask concept, neither of my multimeters do it that way. Maybe there should be a linux-gpib-scpi class?

To read something from the prema I send "VDR3L1PFS0" and when doing a read I get "+1.000001E+1VDR3A0T4S0Q0MOP0D0B0" back, as far as I understand from the manual that is the only way to communicate and don't really fit the "ask"-model.

Well, what is missing?  As far as I understand it, the basic operations on the bus are 'read' and 'write', while 'ask ' is just a shortcut that calls 'write' and then 'read'.  This is how the VXI-11 and USBTMC fdrivers work, anyway, and they're supposed to be equivalent to GPIB.  You can also read just a specific number of characters, if reading more than that causes problems.  It looks like when you read, you get a measurement, plus a bunch of status information.  I imagine you get a similar string if you read without issuing a write call first.  I think you're going to have to do a bit of creative parsing to get all of the status information organized, but I don't think a rewrite of the underlying library is required.  Take a peek at the power meter drivers in Python IVI, agilent436A and agilent437B.  They aren't terribly complete, but they have a very non-SCPI like interface.

I can not read without first having sent a command and when I do read a new measurement will be taken, the prema will block for one second in continuous mode (1 Hz update is the default) per read, and probably if set to measure on read will trigger a new measurement.
What I'm thinking now is to...  < >... hum, good! The front-panel buttons on the prema locks (apart from the "LOCAL" button) </  >
that there is a set of variables in the prema-dmm class holding the last read configuration and returning those values when a client request information. If a user changes the settings the information of course will be invalid. I guess that for SCPI-instruments the information is taken from the instrument directly?

[alex.forencich]

I can not read without first having sent a command and when I do read a new measurement will be taken, the prema will block for one second in continuous mode (1 Hz update is the default) per read, and probably if set to measure on read will trigger a new measurement.
What I'm thinking now is to...  < >... hum, good! The front-panel buttons on the prema locks (apart from the "LOCAL" button) </  >
that there is a set of variables in the prema-dmm class holding the last read configuration and returning those values when a client request information. If a user changes the settings the information of course will be invalid. I guess that for SCPI-instruments the information is taken from the instrument directly?

Hmm, that's interesting that it forces a measurement when you read.  There is no way to read without taking a measurement, just to get all of the status information?

Most of the SCPI type drivers also cache everything in local variables.  The caching means that multiple reads of the same parameter will only result in one actual query to the instrument.  It's assumed that nobody is monkeying around with the instrument while it is being controlled remotely.  If you want to ensure this isn't a problem, enable the local lockout.  If you don't want to make this assumption, then you can turn off caching or clear the cache (either set instrument.driver_operation.cache = False to disable the cache, or call instrument.driver_operation.invalidate_all_attributes() to clear the cache).  Take a look at the existing drivers to see how the caching system is set up.  It's pretty simple, and the cache check methods actually look at the call stack so you don't have to pass in the property name every time you need to check or update the cache, unless you are updating the cache for a different property.  You will notice that on some drivers, setting certain properties will invalidate several others. 

The caching is probably reasonable for your instrument.  I'm just wondering what the best implementation would be.  You may have to have two 'master methods' - one to set all of the proper settings and take a measurement, and one to take a dummy measurement and then read in all of the settings.  Unless you can find a way to read the settings without taking a measurement, anyway.  The danger of forcing a measurement is that if it's set to take a triggered measurement, you may get a rather unexpected timeout and then possibly leave the instrument in a strange state (waiting for trigger).  This may or may not be a problem with your meter, though. 

[wiss]

I think this is the only way, the gpib-section in the manual is only a few pages... but on the other hand I've only got like 3 evenings of experience
I'm thinking of taking a dummy VDC reading in "initialize" and then update the cache on every read or software change.

[alex.forencich]

I would say take a dummy reading on the first read. No sense in taking a dummy reading on init if nothing is ever read. Also, enough experimentation could find a way to skip the dummy read, but you never know.

[wiss]

This dummy-read will be the first point where the non-presences of the instrument will be noticed (like GPIB-cable fell out), therefore I'd like to have it in the "fopen"-routine.

[alex.forencich]

Well, whatever you think works best.  The DiCon fiber optic switch driver does something along those lines; it queries the switch configuration (system:config?) on initialization to figure out what modules are installed and populate all of the proper fields accordingly. 

Also, I just finished reworking how Python IVI uses the instrument interface.  If the ask, ask_raw, read, and/or write calls are missing, they will be emulated.  The only required calls are now read_raw and write_raw.  So if a custom interface is required, all it has to do is implement those two functions, and then it can be passed to Python IVI in place of a resource string.  This might be useful for uncommon interfaces.  It also means that you should now be able to use Python IVI with PyVISA, simply by passing a PyVISA instrument to Python IVI in place of the resource string.  Unfortunately, I am unable to test this at the moment as I do not have an accessible installation of NI VISA. 

[alex.forencich]

I just got my Scientific Linux VM working again, and I properly implemented PyVISA support.  Now, if you have PyVISA installed, Python IVI will fall back on PyVISA if other communication interfaces are not installed.  It is also possible to tell Python IVI to prefer PyVISA, in which case it will try PyVISA first and then fall back on other options. 

[awallin]

FWIW, some notes on how to use GPIB under linux, tested with two different NI devices (USB and PCI-E card)
http://www.anderswallin.net/2013/11/gpib-on-linux/

I've also used a time-interval counter through Ethernet based LXI, but I fail to remember the python library name...

[Noise Floor]

Python IVI is only an interface layer, there is no GUI component to it. You could use python IVI to read data from your instruments and then use matplotlib or similar to graph the data. I am not sure what the best real-time plotting solution would be, unfortunately.

NumPy + Matplotlib?

[alex.forencich]

Python IVI is only an interface layer, there is no GUI component to it. You could use python IVI to read data from your instruments and then use matplotlib or similar to graph the data. I am not sure what the best real-time plotting solution would be, unfortunately.

NumPy + Matplotlib?

That would be one solution.  Not sure how well matplotlib works for real-time plotting, though. 

There was a mention of Kst on another post here for plotting logged data.  It looks like a pretty promising solution.  I will look in to putting together a sample logging script that can be used with Kst, as that could be a very powerful combination.