Just got my gpib-card last week and started to play around a bit with python, I'll check this out!
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.
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!
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.
I guess that implementing the DMM-class will be the start
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.
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.
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.
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
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?
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.
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?