Raspberry Pi for GPIB and data analysis: very easy and fully equipped

[e61_phil]

Hi,

based on MiDis description I set up a simple script which fully installs GPIB on a Raspberry Pi based on Rasperry Pi OS (with or without GUI).

The goal was to provide an as simple as possible solution to setup a Pi with everything you need to use GPIB with an Agilent or NI USB-GPIB adaptor.

After installing the Raspberry Pi OS on your Pi (by using Raspberry Pi Imager for example) you just need to copy&paste these two lines into the console:

Code: [Select]

sudo apt update && sudo apt -y upgrade && sudo apt-get -y install --reinstall raspberrypi-bootloader raspberrypi-kernel && sudo apt-get -y install raspberrypi-kernel-headers git
reboot the Pi (This is unfortunately neccessary, because there a sometimes problems to have the right kernel headers for the running kernel)

Code: [Select]

sudo reboot
and then this line (without the [ url ] tags. Better go to the GitHub page and copy from there):

Code: [Select]

mkdir ~/repos && cd ~/repos && git clone [url]https://github.com/PhilippCo/meas_rpi.git[/url] && meas_rpi/install.sh
The script, examples and so on are hosted on GitHub https://github.com/PhilippCo/meas_rpi Please check that URL for the latest instructions!




The script will not only compile and install linux-GPIB to work with Agilent and NI adaptors, it will also install the following:

- PyVISA for Python3 (no it isn't big, it is just a couple of 100kB)
- a Vxi11 Server which acts as a poor mans Agilent E5810. With that you can use the Pi as a GPIB to Ethernet bridge
- my testgear lib to control instruments (no need to use it, but it makes many things easier)
- Jupyter Lab as a Service. This provides a web based development enviroment to control your instruments and run data analysis completely on the Pi without the need to install something else than a browser on your PC (http://<Pi IP>:8888 password:1281)
- Everything you need to do some data analysis in Python: Numpy, SciPy, Pandas, Matplotlib and so on

If you don't like pyvisa (for whatever reason) you can also use vxi11:

Code: [Select]

>>> import vxi11
>>> instr = vxi11.Instrument('TCPIP::192.168.2.48::gpib0,4::INSTR')
>>> instr.ask("*IDN?")
'HEWLETT-PACKARD,34401A,0,10-5-2'
If you run your meaurement script in Jupyter Lab, it will go on even if you close the browser.

I tested it on Raspberry Pi 4, Raspberry Pi 3B and Raspberry Pi 400

Best regards
Philipp

[ScoobyDoo]

Hello e61_phil - this is a major achievement (milestone) for Voltnuts community - unfortunately a lot of people have not yet understood the impact of your work !

GREAT JOB - well done !

Un saludo / Best regards
ScoobyDoo

[notfaded1]

Yeah thanks Phil... I'll try your setup too.  Love to see more of this kind of thing here! 

Bill

[e61_phil]

Thanks for your feedback!

I added a very simple Jupyter Notebook to update all the repos on the Pi. This way it is easy to add more examples and so on without setting up the Pi again.

Just open the Jupyter Lab (<RPI IP>:8888 in your browser) and click "Restart Kernel and run all".

There is also an even simpler Notebook to shutdown the Pi. There is no need to use the linux console if you just want to control some testgear.



I also added a analysis subdirectory with a simple example of an INL calculation. That notebook takes the Transmile data from TiNs Server (branadic showed it another thread) and calculates the INL. Everything happens on the Pi. You can interactely zoom in and out into the graph, resize ist and everything you know from MATLAB or similar tools. Just to show that it is really simple to start with Jupyter.

[baltersice]

Thank you for posting this, great work!!
Installation went fine on a Raspberry Pi Zero W V1.1 as far as I can tell, only JupyterLab is slow on that kind of hardware.

Unfortunately my Cheap (139.33 EUR) Fake NI GPIB-USB-HS bought on eBay in Feb 2020 refuses to cooperate. Curiously it works fine with a fresh, up to date LabView under Windows. But after multiple attempts at getting it to work with linux-GPIB on all the Raspberry Pi models (3, 4, zero) with all available Kernels and OS versions (even the new 64 bit Raspberry Pi OS for the 4) I have to conclude that it's not meant to be. Gotta stick with my TAMS L488 and its noisy PoE for now.

Here's how it looks. I would stay clear of cheap eBay listings in 'New' condition. Perhaps the cheap fake Agilent adapter works better? 

[martinr33]

So I am stuck trying to get my Agilent E5810A to show up.

Is there a configuration file somewhwere that I am missing? I don't see how to set it up.

Any ideas appreciated!

[Johnny10]

 

[gamalot]

Thank you for posting this, great work!!
Installation went fine on a Raspberry Pi Zero W V1.1 as far as I can tell, only JupyterLab is slow on that kind of hardware.

Unfortunately my Cheap (139.33 EUR) Fake NI GPIB-USB-HS bought on eBay in Feb 2020 refuses to cooperate. Curiously it works fine with a fresh, up to date LabView under Windows. But after multiple attempts at getting it to work with linux-GPIB on all the Raspberry Pi models (3, 4, zero) with all available Kernels and OS versions (even the new 64 bit Raspberry Pi OS for the 4) I have to conclude that it's not meant to be. Gotta stick with my TAMS L488 and its noisy PoE for now.

Here's how it looks. I would stay clear of cheap eBay listings in 'New' condition. Perhaps the cheap fake Agilent adapter works better? 

The NI GPIB-USB-HS that I bought a few months ago looks very different. Mine is even cheaper. If you buy it directly on Taobao in China, it only costs 450 RMB (about 59 Euro, 70 US dollars, or 95 Australian dollars). I haven't actually used it yet, maybe I will do some testing later.

[e61_phil]

So I am stuck trying to get my Agilent E5810A to show up.

Is there a configuration file somewhwere that I am missing? I don't see how to set it up.

Any ideas appreciated!

What do you mean by show up?

Which instrument do you want to control? Do you want to use py-visa directly, my testgear lib or linux-gpib lib?

Best regards
Philipp

[e61_phil]

Perhaps the cheap fake Agilent adapter works better? 

Thanks for your feedback!

I'm currently on vacation, but I have a clone Agilent one at home. I will test it end of next week. I tested just original Agilent and NI so far (and E5810).

Best regards
Philipp

[Irv1n]

My original Agilent and NI adapter works good! Great solution out of the box!

[KE5FX]

Thank you for posting this, great work!!
Installation went fine on a Raspberry Pi Zero W V1.1 as far as I can tell, only JupyterLab is slow on that kind of hardware.

Unfortunately my Cheap (139.33 EUR) Fake NI GPIB-USB-HS bought on eBay in Feb 2020 refuses to cooperate. Curiously it works fine with a fresh, up to date LabView under Windows. But after multiple attempts at getting it to work with linux-GPIB on all the Raspberry Pi models (3, 4, zero) with all available Kernels and OS versions (even the new 64 bit Raspberry Pi OS for the 4) I have to conclude that it's not meant to be. Gotta stick with my TAMS L488 and its noisy PoE for now.

Here's how it looks. I would stay clear of cheap eBay listings in 'New' condition. Perhaps the cheap fake Agilent adapter works better? 

Interesting, that's the first actual fake GPIB-USB-HS adapter I've seen.  The units I've purchased out of China all look like gamalot's photo, and are either genuine or extremely good copies.  Do you remember the name of the seller you bought yours from?

[AaronD]

Nice!  It appears, though, that it works differently from what I would expect for something like this.  Not that that's necessarily a bad thing; just curious.

Since GPIB is essentially ASCII on an 8-bit parallel interface, I would expect an 8-bit-at-a-time standardized API like a virtual UART, that I can use like any other UART (echo "*IDN?" > /dev/gpib0 && cat /dev/gpib0), except that the "black box" between the standard API and the real world has an 8-bit shift register in it.  (or doesn't if you imagine that a serial port does)  Is there a reason for not doing it like that?

[martinr33]

I am trying to use the Jupyter notebok configuration from your Github distribution. Everything seems to be complete, the installation finished.

I am using the simple example script that just pulls a read from the instrument.

What  I don't understand is, how do I configure the IP address of the E5810A? e.g. 192.168.0.157?

[e61_phil]

Nice!  It appears, though, that it works differently from what I would expect for something like this.  Not that that's necessarily a bad thing; just curious.

Since GPIB is essentially ASCII on an 8-bit parallel interface, I would expect an 8-bit-at-a-time standardized API like a virtual UART, that I can use like any other UART (echo "*IDN?" > /dev/gpib0 && cat /dev/gpib0), except that the "black box" between the standard API and the real world has an 8-bit shift register in it.  (or doesn't if you imagine that a serial port does)  Is there a reason for not doing it like that?

I don't know what you want to do and if it really makes sense to do it not in python, but you could do something like that:

Code: [Select]

import sys
import testgear

dmm = testgear.HPAK.HP34401A(gpib=3, gwip="192.168.2.88")

for line in sys.stdin:
    sys.stdout.write(dmm.query(line.strip()))

That will take stdin and sends it to the instrument (a 34401A in this example). The output is then writte to stdout. If you save the file as piper.py you can use it like this:

Code: [Select]

echo "*IDN?" | python3 piper.py


[e61_phil]

I am trying to use the Jupyter notebok configuration from your Github distribution. Everything seems to be complete, the installation finished.

I am using the simple example script that just pulls a read from the instrument.

What  I don't understand is, how do I configure the IP address of the E5810A? e.g. 192.168.0.157?

If you're using a gateway like the E5810 (or the Pi itself, if you run the Python on another machine). Just specify the Gateway IP:

Code: [Select]

dmm = testgear.HPAK.HP34401A(gpib=3, gwip="192.168.2.88")


[AaronD]

I don't know what you want to do and if it really makes sense to do it not in python...

I'm thinking that I'm already familiar with bash and not so much in python, and I have an off-brand power supply with GPIB on the back.  (I really doubt it's in anyone's library of drivers)  I want to discover what it can do from that port and how the responses are formatted, and then use it for some quick-and-dirty automated testing with minimal development effort for each test.  I'm also looking at a USB oscilloscope and logic analyzer for that Pi as well...

...but you could do something like that:

Code: [Select]

import sys
import testgear

dmm = testgear.HPAK.HP34401A(gpib=3, gwip="192.168.2.88")

for line in sys.stdin:
    sys.stdout.write(dmm.query(line.strip()))

That will take stdin and sends it to the instrument (a 34401A in this example). The output is then writte to stdout. If you save the file as piper.py you can use it like this:

Code: [Select]

echo "*IDN?" | python3 piper.py


Okay, I can copy/paste as well as anyone else, but what's the IP address for?  Doesn't everything run on the same Pi with no network required at all?

[e61_phil]

Okay, I can copy/paste as well as anyone else, but what's the IP address for?  Doesn't everything run on the same Pi with no network required at all?

Sorry, I tested it with my notebook here on vacation. My 34401A is sitting at home behind my E5810 with this IP address. Just delete that parameter and it will work completely local.

[e61_phil]

To be clear: Most of the software is from other people and I just combined them. But one of the things which is from me, is the testgear lib. The idea behind this lib is to create an easy to access and common interface for the testgear we use quite often.
One of the goals was that one can write a script and after that change the instruments used without changing anything on the script.

At the moment there are two important classes of instruments: meters and sources (and some instruments can be a meter and a source).

The first step with testgear is alwas to import the lib:

Code: [Select]

import testgear
After that you can create your instruments:

Code: [Select]

dmm = testgear.HPAK.HP3458A(gpib=3)

Possible parameters for this are:
visastr: You can directly specify the VISA String to talk to the instrument
gpib: GPIB address
gwip: GPIB Gateway (Pi or E5810)
ip: IP address of the instrument in case your using the ethernet interface of an instrument


In case of a meter you will configure it in the next step. In case of a DCV measurement like this:

Code: [Select]

dmm.conf_function_DCV(mrange=10, nplc=100, HiZ=True)

The idea of putting the function of the instrument in the method name and not in a parameter was, that the autocompletion (also available in Jupyter Lab) is much more helpful this way. Just start to write dmm.conf in the Jupyter Lab and hit <tab> and you can select between the functions.

I also tried to make everything as readable as possible. Some parameter names may appear long, but it should help to directly understand the code.

To get a reading of your DMM just use

Code: [Select]

dmm.get_reading()
That will trigger a reading, fetch the data and return a float value


If you're controlling a source. The most important method is

Code: [Select]

set_output(voltage=None, current=None, enabled=True, frequency=0, resistance=None, fourWire=False, channel=1)

Lets assume you want to generate 1Vrms with 100Hz. Just use

Code: [Select]

source.set_output(voltage=1, frequency=100)
That will create an 1Vrms output with 100Hz, not matter if your source is a AC calibrator (Valhalla 2703 for example, a MFC (Fluke 5730A) or a signal generator. You always get 1Vrms.

Same is true for DCV. Just set frequency to zero (which is default) and it doesn't matter if the source is a power supply, MFC, DCV calibrator, the DC source of your electrometer or a signal generator.
And it is again the same for resistance.

That means you can write a test script to compare resistances against your 3458A, 8588A, 34401A, 8508A.... sourcing from a 5730A or 5450A or whatever and you don't need to change your script. Just change the instruments.


There is still a lot of work to do and hopefully one can add more and more instruments

[AaronD]

Sorry, I tested it with my notebook here on vacation. My 34401A is sitting at home behind my E5810 with this IP address. Just delete that parameter and it will work completely local.

Ah!  That makes sense now.  Thanks!

...But one of the things which is from me, is the testgear lib. The idea behind this lib is to create an easy to access and common interface for the testgear we use quite often.
One of the goals was that one can write a script and after that change the instruments used without changing anything on the script.

...

That means you can write a test script to compare resistances against your 3458A, 8588A, 34401A, 8508A.... sourcing from a 5730A or 5450A or whatever and you don't need to change your script. Just change the instruments.

There is still a lot of work to do and hopefully one can add more and more instruments

And I see what you're doing now too.  That's a good idea!

[martinr33]

OK, first results in hand.

1) If the E5810A gets a command it doesn't like, it seems that I have to restart it.
2) The Jupyter environment works great.

Here's my first working script, the E5810A is at 192.168.0.246:

import testgear
dmm = testgear.HPAK.HP3458A(gpib=12, gwip="192.168.0.246")
dmm.conf_function_DCV(mrange=10, nplc=100, HiZ=True)
dmm.get_reading()
9.999929798     <-----this is the output from the above line

Thanks again for making this work (and thanks also to TiN who helped me get me rolling).

[e61_phil]

Very good to hear it works for you
Do you use it in Jupyter Lab/Notebook or in a python script on the console?

I added a very simple logging example, which logs into an Excel file. I like logging into Excel files, because one can easily open such files and have a look without writing any code. Another advantage of xlsx is, that it is zipped xml data. If you create very long logs it is automatically compressed.

If you don't like the excel format, there are thousands of alternatives.

In a second Jupyter Notebook I made an example how to read the data into a Pandas dataframe and plot the data.

[Anders Petersson]

But one of the things which is from me, is the testgear lib. The idea behind this lib is to create an easy to access and common interface for the testgear we use quite often.
One of the goals was that one can write a script and after that change the instruments used without changing anything on the script.
[...]
There is still a lot of work to do and hopefully one can add more and more instruments

This is an interesting topic. When getting familiar with automation of test equipment, I've seen several Python libraries for this. That's not surprising, given how well such an abstraction conforms with best practices of software development and how easy it is to wrap a SCPI command in a function.

However, none of the Python libraries I've seen are very complete. I haven't found my set of instruments implemented anywhere. Also, the APIs don't usually offer many functions. This shows that it's easier to start your own library than to extend an existing library (which would benefit all users). With hundreds of instrument models available and a fragmented scene of libraries, none will be very complete.

python-ivi is one attempt, but even this one project is fragmented: https://www.eevblog.com/forum/metrology/software-for-automated-testing-(scpi)/msg3397668/#msg3397668

For a library to gain wide use the APIs of its base classes must suit many use cases. Also, it would help if developers can reap the benefit of extra functionality. For example, PyMeasure provides some basic graphical user interface, plotting and experiment sequencing.

These are things I ponder as I too write my own instrument drivers...

[mendip_discovery]

Out of curiosity why can't a Pi (+Hat) or Arduino not be trained to translate the GPIB stuff directly and avoid the whole expensive hardware to interface with?

[e61_phil]

But one of the things which is from me, is the testgear lib. The idea behind this lib is to create an easy to access and common interface for the testgear we use quite often.
One of the goals was that one can write a script and after that change the instruments used without changing anything on the script.
[...]
There is still a lot of work to do and hopefully one can add more and more instruments

This is an interesting topic. When getting familiar with automation of test equipment, I've seen several Python libraries for this. That's not surprising, given how well such an abstraction conforms with best practices of software development and how easy it is to wrap a SCPI command in a function.

However, none of the Python libraries I've seen are very complete. I haven't found my set of instruments implemented anywhere. Also, the APIs don't usually offer many functions. This shows that it's easier to start your own library than to extend an existing library (which would benefit all users). With hundreds of instrument models available and a fragmented scene of libraries, none will be very complete.

python-ivi is one attempt, but even this one project is fragmented: https://www.eevblog.com/forum/metrology/software-for-automated-testing-(scpi)/msg3397668/#msg3397668

For a library to gain wide use the APIs of its base classes must suit many use cases. Also, it would help if developers can reap the benefit of extra functionality. For example, PyMeasure provides some basic graphical user interface, plotting and experiment sequencing.

These are things I ponder as I too write my own instrument drivers...

Yes, wrapping around SCPI is very simple for most cases. Trigger the instrument and get a reading is just READ? for most of the newer instruments. But we all here in the metrology section deal with many older instruments and they have sometimes very crude commands.

Most older instruments just want to have a range specified, they can't handle conf_function_DCV(mrange=3.87) directly. Or getting the output status of a Fluke 5730A calibrator needs to look up for a specified bit in the status register. And again other instruments (like my Knick JS3010 calibrator) aren't able to switch the output off an on again. Therefore, you need to keep some state of the instrument in the class.

And you're also right: Such a lib is never complete. My goal was to have something I can use without any manual. Just start writing code and use auto-completion. Having a common API for every instrument also implies that it can only represent a subset of functions which are shared with most of the instruments.

An example are the different AC modes of an HP 3458A. conf_function_ACV just looks simply like that internally:

Code: [Select]

    def conf_function_ACV(self, mrange=None, nplc=100, AutoZero=True, HiZ=True, channel=1):
        """configures the meter to measure ACV. if range=None the meter is set to Autorange"""
        self.write("PRESET NORM")
        self.write("ACV")
        self.write("SETACV SYNC")
        self.__set_range(mrange, nplc)
        self.__autoZero(AutoZero)
        self.__hiZ(HiZ)

SYNC is the most accurate mode in most cases, but it might not always be what you want. In such cases one can directly talk to the instrument:

Code: [Select]

dmm.write("SETACV RNDM")

To prevent that from breaking appart as soon as your using not a HP 3458A you can use a small helper function which compares the type of class:

Code: [Select]

dmm.conf_function_ACV(mrange=10)
if dmm.is_type_of("HP3458A"):
   #we have an 3458A and don't want to have SYNC mode
   dmm.write("SETACV RNDM")

But that already breaks with the idea of a common interface