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

[e61_phil]

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?

That is possible and a colleauge of mine build such a shield for a Pi. It just uses the GPIB line driver ICs and the rest is bit banging with RPi IOs. But the USB Adaptors (especially the clones) are so cheap nowadays, that it doesn't make so much sense to build a own one.

[Anders Petersson]

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.

To clarify, I am in favor of instrument drivers that abstract the commands, not only for instruments with exotic syntax but also for common SCPI commands.

Syntax is easy to abstract, but "semantics" (differing ways of operation) is harder. Your example of HP 3458A "SETACV RNDM" is a benign example though, as the common API can include a conf_sync_mode() method that all drivers leave blank except the 3458A driver. The meaning of such a method can however be confusing for someone unfamiliar with 3458A. Perhaps it's better to always enable SYNC in the 3458A driver.

Other functions can be harder to generalize. For example, Keithley DMM6500 etc. have a "digitizer" mode for recording high-frequency current or voltage readings. Unclear if a high-level API without this concept can utilize this functionality, and if an engineer even wants to disregard this detail.

IVI did define common interfaces: "By using IVI class drivers in your test program, you can change hardware without changing test code or recompiling your application."
https://zone.ni.com/reference/en-XX/help/370430H-01/ni_ivihelp/ivi_class_drivers_overview/
And their (long) definition for DMM:
https://www.ivifoundation.org/downloads/Class%20Specifications/IVI-4.2_DMM_2016-10-14.pdf

I don't know which type of API is the best. I just argue that the choice is very important for getting people onboard.

[e61_phil]

Perhaps it's better to always enable SYNC in the 3458A driver.

That's what I did, but it somehow hides the functionality of the 3458A. If you're not familiar with the 3458, you will never know that there is more than one method to measure ACV.

There are also other functions which might be not so important. For example my Keithley 617 has a V/I Ohms mode and displays Ohms directly by using the controllable voltage source and measuring the current. Such things, I would just simply rebuild in software, by conf_function_DCI() and setting the voltage source (also in software). But there is much more..

Other functions can be harder to generalize. For example, Keithley DMM6500 etc. have a "digitizer" mode for recording high-frequency current or voltage readings. Unclear if a high-level API without this concept can utilize this functionality, and if an engineer even wants to disregard this detail.

These digitizing is also available for the HP 3458A, Fluke 8588A and Keysight 34470A.

I started to play around with that for the 3458A. I also used these functions a lot with the 34470A and 8588A, but it isn't implemented in the lib yet.

Code: [Select]

digitize(mrange=10, samples=512, srate=20e-6, aperture=3e-6, delay=0):

The 3458A has not only a digitizing, but also two sampling modes.
directsampling and  subsampling(mrange=10, samples=500, srate=10e-9, delay=500e-9). These modes are using the S&H and subsampling can sample signals with up to 100MS/s (sampling mode)

Configuring the sample rate, aperture time and so on ist just one thing. Another important thing is the trigger setup. I don't know how that should be made to be easily configurable.

IVI did define common interfaces: "By using IVI class drivers in your test program, you can change hardware without changing test code or recompiling your application."
https://zone.ni.com/reference/en-XX/help/370430H-01/ni_ivihelp/ivi_class_drivers_overview/
And their (long) definition for DMM:
https://www.ivifoundation.org/downloads/Class%20Specifications/IVI-4.2_DMM_2016-10-14.pdf

I don't know which type of API is the best. I just argue that the choice is very important for getting people onboard.

In the end IVI would be more flexible and much more people have thought about it . In the beginning it was just a nice project to play around with classes in python. In the meantime there are some people who are using it for real measurements.

But nobody needs to use testgear. One can just ignore it and use the rest of the Raspberry Pi Setup.

It would be interesting which meters are currently missing and if there are some special functions which are often used and cannot be used with the actual quite simple scheme.

[AaronD]

Just happened to discover this today, linked from another discussion:
https://www.eevblog.com/forum/testgear/python-based-instrument-control/

Does that mean anything?

---

The other discussion is here:
https://www.eevblog.com/forum/oshw/openlab-standard/

[Anders Petersson]

Just happened to discover this today, linked from another discussion:
https://www.eevblog.com/forum/testgear/python-based-instrument-control/

Does that mean anything?

That's the IVI library for Python. Since that thread, various versions (forks) of the library have started so I don't know if there's a definitive version. It might be the solution to the question of generic instrument control but I don't have much experience of the library myself so I can't tell.

[e61_phil]

Back to the rest of the setup:

Just a quick tip. If you run your logging script in jupyter lab it will keep running even if you close the browser. The only drawback is, that you can't see the output anymore. A quick workaround is to redirect the standard output to a file

Code: [Select]

import sys
sys.stdout = open("log.txt", "w")

From that point on everything you write to stdout (print() for example) will be redirected in that file. Know you can monitor the file with tail -f log.txt for example.

[krulls]

I'm late to the game here, but am trying to install on a RPi 3B+ and after the a lot of loading and installing I get:
Reading package list... Done
Building dependency tree
Reading state information... done
E: Unable to locate package reinstall

I'm a complete beginner so any help would be appreciated!

[alm]

Start by posting the command that you're trying but failing to run, and the relevant output you get (when in doubt, just include everything). My crystal ball is a bit opaque today, but it might be that you're missing the dashes, or have a space after the dashes, in sudo apt-get -y install --reinstall raspberrypi-bootloader raspberrypi-kernel.

[krulls]

ALM, many thanks for your reply. I went back and carefully typed in the commands again and it appears to have worked! It's quite possible my old fumbly fingers slipped and added a space where there should not have been one. I'll move along to the next part of the installation and see if I can do that without mistakes. Many thanks again!

[krulls]

After successful completion of the first line for installation and going to github and reading the instructions there, I executed:
mkdir ~/repos && cd ~/repos && git clone https://github.com/PhilippCo/meas_rpi.git && meas_rpi/install.sh

It took quite a while but finally the last few lines on the screen say:
* vxi-bridge.service - VXI Bridge
   Loaded: loaded (/lib/systemd/system/vxi-bridge.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Tue 2022-01-18 15:05:07 CST; 71ms ago
  Process: 17671 ExecStart=/usr/bin/python3 /home/pi/repos/python-vxi11-server/bridge.py (code+killed, signal=HUP
 Main PID: 17671 (code=killed, signal=HUP)

Jan 18 15:05:07 raspberrypi systemd[1]: started VXI Bridge.
Jan 18 15:05:07 raspberrypi systemd[1] vxi-bridge.service: Main process exited, code=killed, status=1/HUP
Jan 18 15:05:07 raspberrypi systemd[1] vxi-bridge.service: Succeeded.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
Lines 1-9/9 (END)

At this point the rpi seemed to be locked up. After a reboot I can see the repos directory and folders within it for meas_rpi and python-vxi11-server.
In the meas_rpi folder, if I run the "example_HP3458A.py" program with an 82357B USB-GPIB adapter connected to my 3458A, I get "Access" and "Ready" green lights on the adapter and a red"Fail" light. Running the program I get a long list of errors, starting with:
libgpib: ibBoardOpen failed to open device file /dev/gpib0
libgpib: No such file or directory
libgpib: error in is_cic()!
Traceback (most recent call last):
  File "/home/pi/repos/meas_rpi/example_HP3458A.py", line 4, in <module>
     inst = rm.open_resource("GPIB0::22::INSTR")
and then many more lines of errors. I wonder if I am missing a crucial part of the installation?

[AaronD]

mkdir ~/repos && cd ~/repos && git clone https://github.com/PhilippCo/meas_rpi.git && meas_rpi/install.sh

That's 4 separate commands chained together with the logical AND operator for conditional logic (&&).  If any of them fails, the rest don't run, and the entire string returns the first failure code, but which one was it that failed?  This structure is designed for conditional logic to make a binary decision, so it doesn't have that detail.  If you wanted that detail as a programmer, you would have each one separately.  So when I see something like that to copy/paste, I usually separate them out and run them independently, watching for failures myself:
mkdir ~/repos
cd ~/repos
git clone https://github.com/PhilippCo/meas_rpi.git
meas_rpi/install.sh

In this case, I suspect that the failure is in the last one, because I can't imagine that the others would produce those messages.  Looking at the file itself on GitHub, my guess is that it got to around line 128 or so, which is where it starts the VXI11 server.  Whether there was something wrong with the download/install or whether your system just wasn't up to snuff is beyond me.

Just because it got to that point, doesn't necessarily mean that everything above it succeeded.  It doesn't check anything before moving on to the next (except for the one that gave the developer some trouble), so there could be an early failure that finally comes to a head way down here.  Do you still have the entire output?

Depending on what it actually did, the recovery may or may not be tricky at this point, since the script may have partially configured things that need to be undone before you try again.  In other words, it may only work for a clean system, and you no longer have that since the first attempt failed partway through.  So what did it do right, and what needs to be fixed up manually?

[alm]

Lines 1-9/9 (END)

I'm wondering if it was actually locked up, or if it was just for some reason showing the output in less. Pressing 'q' might have allowed the script to continue.

libgpib: ibBoardOpen failed to open device file /dev/gpib0

This means it not seeing the GPIB driver. Assuming it indeed failed around line 128, all the GPIB setup should have happened before that line. So I would second AaronD's request for the full output of the install.sh command. You can attach it to your post as a .txt file.

It might indeed well be that the easiest way to recover is to start from scratch. But let's look at the output first if available.

[krulls]

AaronD and ALM,
Thanks so much for your valuable input! I didn't think to capture the entire output, my inexperience showing through again. Would it make sense to run the install.sh again and capture the entire output, or would that muddy the waters more?

[alm]

Looking at the install.sh script, I think it should be fine to rerun it and capture the output. I don't see anything non-idempotent (can not be applied multiple times). There will probably be some extra error messages about things already existing, but no other problems as far as I can see.

If you again get something with "Lines 1-.../... (END)" at the end, try pressing the q key instead of rebooting it.

[krulls]

Last reply didn't work. I had apparently attached an incorrect file type. I ran install.sh again and when it stopped at "Lines 1-9/9" I entered q and it carried on to the end with numerous messages about "xyz" already installed. At the end it told me to reboot and after sudo reboot I attached the 82357B and connected it to the 3458A. I got the same two green lights and the red fail light. When I ran the 3458A example program I got the errors shown in the attached file, if it goes through as a .txt file this time. Again, thank you for your help and patience!

[AaronD]

I ran install.sh again and when it stopped at "Lines 1-9/9" I entered q and it carried on to the end with numerous messages...

What were those messages?

[krulls]

The messages that I noted stated that programs or files the install was attempting to install were already installed and were the latest versions. It's possible I missed some as I did look away from the screen to do other things. I'm not a computer guy but I wondered if it's possible to have the system log all the commands and responses to a file? There were hundreds of lines of commands and responses so it's likely I missed some. I was just happy to see it continued on and appeared to complete the install this time. I'm happy to run it all again if there's a way to capture all the information scrolling down the screen as the install progresses. Or failing that I'm happy to try to delete everything and try a fresh installation if I can figure out how to do that. Again, many thanks for helping an old guy try something new!

[AaronD]

...have the system log all the commands and responses to a file

command with arguments > file OR command with arguments >> file

The latter appends to the end of the file, which is useful for an ongoing log.  The former replaces the file so that it only contains the output of the last time the command ran.

OR command with arguments | tee file

That one pipes (|) the command's output to tee's input, and all tee does is copy its input to its own output and to that file.

Also, there are actually *two* outputs, stdout for normal output and stderr for errors, and the terminal catches both.  Redirection and pipes, however, only catch stdout.  To get both, you need to redirect stderr to the same place, like this: command with arguments 2>&1 | tee file  That sends the original stream 2 (stderr) to the same place as the original stream 1 (stdout), and then does the redirection.
(They're separate so that you can do some preliminary filtering by sending them to different places, provided of course that each command follows that convention.  The built-in utilities do, but a freshman project probably doesn't.)


There are TONS of utilities like that (cat and grep are often useful across a pipe...), and even more if you apt install moreutils.  Once you have that, you can do command | ts >> file, which puts a timestamp on each line.

man x to see in detail what x does and how to tweak it.


None of these record the command though, only the output.  The only way I know to capture the commands too is to set the terminal's scrollback way high and then copy/paste after it's done.  (Ctrl-C is not copy, and Ctrl-V is not paste, inside the terminal.  Those have other meanings, like "stop the running program".  A lot of terminals use Ctrl-Shift-C/V for copy/paste, which isn't too far different, but you still have to remember.  Or if you're unsure, you can use the right-click menu.)

But even with that, it still won't echo the commands from inside a script, like Windows does.  You'd need to modify the script, like I do with some of mine, to explicitly print what it's about to do before it does it.

[krulls]

Thanks for that information. I'm not a programmer at all so it will take me a bit to digest all that.

[e61_phil]

Sorry, I completely missed this discussion here.

Is the problem still existent? I will test it on a Pi later today and update the repo.

@krulls: Is your setup working now?

[krulls]

Hi e61_phil
Yes, the problem still exists as I haven't been able to get back to it. A load of things I hadn't planned on have been taking all my time, as you can see from the lateness of my reply. Any help for an old non-computer guy would be greatly appreciated. I thought I had someone locally who would take an SD card I was to provide and create a known good installation but that fell through.
Thanks to all who have helped!

[e61_phil]

Hi e61_phil
Yes, the problem still exists as I haven't been able to get back to it. A load of things I hadn't planned on have been taking all my time, as you can see from the lateness of my reply. Any help for an old non-computer guy would be greatly appreciated. I thought I had someone locally who would take an SD card I was to provide and create a known good installation but that fell through.
Thanks to all who have helped!

I installed that recently on a raspberry pi 4 and it worked without issues. Maybe we can have a look together on your pi via a remote session

[French_Nikolas]

I use a raspberry pi v2.1, with Raspberry Pi OS (Legacy) [Kernel version: 5.10, Debian version: 10 (buster)], and 4GB RAM.
I get an exception :

Exception:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pip/_internal/cli/base_command.py", line 143, in main
    status = self.run(options, args)
  File "/usr/lib/python3/dist-packages/pip/_internal/commands/install.py", line 338, in run
    resolver.resolve(requirement_set)
  File "/usr/lib/python3/dist-packages/pip/_internal/resolve.py", line 102, in resolve
    self._resolve_one(requirement_set, req)
  File "/usr/lib/python3/dist-packages/pip/_internal/resolve.py", line 256, in _resolve_one
    abstract_dist = self._get_abstract_dist_for(req_to_install)
  File "/usr/lib/python3/dist-packages/pip/_internal/resolve.py", line 199, in _get_abstract_dist_for
    skip_reason = self._check_skip_installed(req)
  File "/usr/lib/python3/dist-packages/pip/_internal/resolve.py", line 170, in _check_skip_installed
    self.finder.find_requirement(req_to_install, upgrade=True)
  File "/usr/lib/python3/dist-packages/pip/_internal/index.py", line 572, in find_requirement
    all_candidates = self.find_all_candidates(req.name)
  File "/usr/lib/python3/dist-packages/pip/_internal/index.py", line 534, in find_all_candidates
    self._package_versions(page.iter_links(), search)
  File "/usr/lib/python3/dist-packages/pip/_internal/index.py", line 702, in _package_versions
    v = self._link_package_versions(link, search)
  File "/usr/lib/python3/dist-packages/pip/_internal/index.py", line 777, in _link_package_versions
    support_this_python = check_requires_python(link.requires_python)
  File "/usr/lib/python3/dist-packages/pip/_internal/utils/packaging.py", line 33, in check_requires_python
    return python_version in requires_python_specifier
  File "/usr/share/python-wheels/packaging-19.0-py2.py3-none-any.whl/packaging/specifiers.py", line 676, in __contains__
    return self.contains(item)
  File "/usr/share/python-wheels/packaging-19.0-py2.py3-none-any.whl/packaging/specifiers.py", line 681, in contains
    item = parse(item)
  File "/usr/share/python-wheels/packaging-19.0-py2.py3-none-any.whl/packaging/version.py", line 28, in parse
    return Version(version)
  File "/usr/share/python-wheels/packaging-19.0-py2.py3-none-any.whl/packaging/version.py", line 219, in __init__
    match = self._regex.search(version)
TypeError: expected string or bytes-like object

This exception occurs 4 times.

Is it normal ?

[e61_phil]

I use a raspberry pi v2.1, with Raspberry Pi OS (Legacy) [Kernel version: 5.10, Debian version: 10 (buster)], and 4GB RAM.
I get an exception :

Exception:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pip/_internal/cli/base_command.py", line 143, in main
    status = self.run(options, args)
  File "/usr/lib/python3/dist-packages/pip/_internal/commands/install.py", line 338, in run
    resolver.resolve(requirement_set)
  File "/usr/lib/python3/dist-packages/pip/_internal/resolve.py", line 102, in resolve
    self._resolve_one(requirement_set, req)
  File "/usr/lib/python3/dist-packages/pip/_internal/resolve.py", line 256, in _resolve_one
    abstract_dist = self._get_abstract_dist_for(req_to_install)
  File "/usr/lib/python3/dist-packages/pip/_internal/resolve.py", line 199, in _get_abstract_dist_for
    skip_reason = self._check_skip_installed(req)
  File "/usr/lib/python3/dist-packages/pip/_internal/resolve.py", line 170, in _check_skip_installed
    self.finder.find_requirement(req_to_install, upgrade=True)
  File "/usr/lib/python3/dist-packages/pip/_internal/index.py", line 572, in find_requirement
    all_candidates = self.find_all_candidates(req.name)
  File "/usr/lib/python3/dist-packages/pip/_internal/index.py", line 534, in find_all_candidates
    self._package_versions(page.iter_links(), search)
  File "/usr/lib/python3/dist-packages/pip/_internal/index.py", line 702, in _package_versions
    v = self._link_package_versions(link, search)
  File "/usr/lib/python3/dist-packages/pip/_internal/index.py", line 777, in _link_package_versions
    support_this_python = check_requires_python(link.requires_python)
  File "/usr/lib/python3/dist-packages/pip/_internal/utils/packaging.py", line 33, in check_requires_python
    return python_version in requires_python_specifier
  File "/usr/share/python-wheels/packaging-19.0-py2.py3-none-any.whl/packaging/specifiers.py", line 676, in __contains__
    return self.contains(item)
  File "/usr/share/python-wheels/packaging-19.0-py2.py3-none-any.whl/packaging/specifiers.py", line 681, in contains
    item = parse(item)
  File "/usr/share/python-wheels/packaging-19.0-py2.py3-none-any.whl/packaging/version.py", line 28, in parse
    return Version(version)
  File "/usr/share/python-wheels/packaging-19.0-py2.py3-none-any.whl/packaging/version.py", line 219, in __init__
    match = self._regex.search(version)
TypeError: expected string or bytes-like object

This exception occurs 4 times.

Is it normal ?

That is not normal. 5.10 should be fine.

Did you do a fresh install?

[French_Nikolas]

Yes, it was a fresh install.

SD card 8Go,
Raspberry Pi OS (Legacy)
Kernel 5.10
Debian v10 (buster)
4GB RAM
nothing else.

installation done through ssh.

[martinr33]

1) Using the HP E5810 and a Data Proof scanner, NI MAX and Python.

The scanner needs a tweak to its termination, or it won't action the request.
Example working code:

inst = rm.open_resource(DataProof)       #PyVisa function - "DataProof" is a fully-formed VISA address string. inst is the short version.
inst.write_termination = '\n'                   # This is the critical change. The scanner won't work otherwise.
inst.write("A05")                                    # Set scanner to A05

On the list: create a library function for this unit for Phil's library.


2) You must use a 32-bit version of the RPi OS, or you will get the painful failures recently reported. I am using a PC to develop, but the code will easily move to the Pi.

 

[MiDi]

2) You must use a 32-bit version of the RPi OS, or you will get the painful failures recently reported. I am using a PC to develop, but the code will easily move to the Pi.

Seems to be a problem with package management and jupyterlab, maybe only on 64bit raspi OS: Install jupyterlab in pip3 throws 'TypeError: expected string or bytes-like object'

Another report of the same error: PhilippCo/meas_rpi: Error when installing

[martinr33]

OK, more baby steps on the way to making Philippe's system work. My end goal is the Raspberry Pi system using Philippe's library and Jupyter notebooks, but my first effort is to get to a functional system on the PC.

Please, no complaints, I know this is ugly and basic. But it also works to get folks started.

You'll need to complete each one, mostly in order, to avoid getting stuck.

1) Get your GPIB adapter or E5810 working and scan the instruments. Make sure you see what you expect to see!
The instruments must be listed for the next step (I think...), if your adapter has simple management software (it may not)

2) Load NI Explorer. This is your basic GPIB interface library. Find and install your instruments in the GPIB tree. They have long names, like the ones in my example code. In the snip attached, these are connected to the E5810.

 
3) Load Thonny. https://thonny.org/.
This is an easy starter environment. Later, Jupyter notebooks and the Raspberry Pi.

4) Load my test program, tweak for your instruments, and walk through any library errors. Thonny has many libraries already available, The only one you might have to hunt down is PyVISA.
The code is messy, and includes a lot of redundant or irrelevant stuff that I left in for reference. Also, the 34420A setup causes non-critical errors.

5) Start your first logging!

Once you are here, you can write code for many instruments.

6) At this stage, we are still hacking at the lowest level. This is where Philippe's libraries will help us. So get this started.

Next steps:
 - Philippe's libraries
 - Jupyter notebooks
 - Move to Raspberry Pi for logging (we'll keep development on the PC)








#This section is not essential, as the instrument names defined in here are local. However, it shows you how a Python function appears.
def InstrumentNames():
#Instrument inventory and aliases. Note that these are local names, so pretty useless.
    HP34420A = 'TCPIP0::192.168.0.110::gpib0,10::INSTR'
    HP3458A2 = 'TCPIP0::192.168.0.110::gpib0,20::INSTR'
    print ('\033[1m','\n',"Instrument    Addr   Name      GPIB Address",'\033[0m')
    print ("HP 34420A      10     HP34420A ",HP34420A)
    print ("HP 3458A2      20     3458A-2  ",HP3458A2)




#These three lines are critical.
import sys
import pyvisa
import time

localtime = time.asctime( time.localtime(time.time()) )

rm = pyvisa.ResourceManager()   #Shorthand for use later on.  when you use "rm", you get the component on the right - in this case, a function.

print("\nList of Instruments Detected\n",rm.list_resources())  # ...so here you see pyvisa.ResourceManager.list_resources()

HP34420A = 'TCPIP0::192.168.0.110::gpib0,10::INSTR'    #These next half dozen populated lines are not essential, but they do list your instruments.
HP3458A2 = 'TCPIP0::192.168.0.110::gpib0,20::INSTR'

print ('\033[1m','\n',"Instrument    Addr   Name      GPIB Address",'\033[0m')
print ("HP 34420A      10     HP34420A ",HP34420A)
print ("HP 3458A2      20     3458A-2  ",HP3458A2)

InstrumentNames()

#34420A init                                #I think this section is also redundant, except maybe for the timeout. Also, the INITs in this code do not work right.
inst = rm.open_resource(HP34420A)
inst.write("*RST;*CLS")
inst.write(":SENS:FUNC:VOLT;:SENS:CHAN 1;:SENS:VOLT:CHAN1:RANG:AUTO ON")
inst.write("VOLTage:DC:RESolution:MIN;VOLTage:DC:NPLCycles:MAX")
inst.timeout = 10


#This is where things start to happen.

f = open("Voltage_standards4.txt", "w")  #w means open for write. CHANGE TO #A (append) if you want to continue runs.
#f.write("Time  \t\t\t\t\t\t2142A     \t\t34420A-1        \t\t34420A-2\t\t8508A\r\n")



#open and read the file after the appending:
#f = open("demofile2.txt", "r")
#print(f.read())
#line = line.rstrip('\r\n') # strip out all tailing whitespace

#34420A commands
#SENSe1:VOLTage:RANGe 10 Channel 1 range 10 mV
#SENSe2:VOLTage:RANGe .1 Channel 2 range 10 mV
#ROUTe:TERMinals FRONt1 Select channel 1
#READ? Channel 1 measurement
#ROUTe:TERMinals FRONt2 Select channel 2
#READ?


#And finally the main loop.

i=1
while (i<50000):
    f = open("Voltage_standards4.txt", "a")
    i=i+1
    f.write(time.asctime(time.localtime(time.time())))
    f.write("\t")
   
   
    inst = rm.open_resource(HP34420A)
    inst.write("ROUTe:TERMinals FRONt1;")
    f.write(inst.query(":READ?").rstrip('\r\n'))
    f.write("\t")
   
   
    inst = rm.open_resource(HP34420A)
    inst.write("ROUTe:TERMinals FRONt2")
    f.write(inst.query(":READ?").rstrip('\r\n'))  #strip return and newline characters so we get one line per set of readings
    f.write("\n")   


print ("Complete!")

[ErnieM]

krulls: I know it has been near forever since you last posted but based on this thread (the OP actually) I was able to get the install to work... but NOT on a Pi 3.

My first attempt on a Pi 3 worked somewhat as I got the driver to install. Connecting an Agilent USB->GPIB got me the beloved green connection light, but little else worked as the back end would not install. I figured out that the old Pi 3 I was using had an old incompatible version of Python, so after struggling to update that I just went to a new copy of NOOBS, but again the install would stall and no joy was there.

I managed to find a Pi 4 I has tucked away, made a clean NOOBS install, and the package installed first time no drips, runs, or errors.

e61_phil: I'm thinking that the Pi 3 has some incompatibility with the package. Besides the unobtanium nature of the Pi these days I am still thrilled with this result as I have been attempting to get GPIB support on a Pi off and on for a few years now.

Thank you for this effort!

[martinr33]

One thing - you must use the 32-bit version of the OS.

[mendip_discovery]

I found I needed to run a 32bit OS as I was having a nightmare with my 2B but read about some issues with 16bit so I tried it and it worked a charm but I wasnt 100% sure so didnt riase it on github as a requirement.