Author Topic: Raspberry Pi for GPIB and data analysis: very easy and fully equipped (Read 15652 times)

e61_phil · « **Reply #25 on:** August 17, 2021, 11:31:14 am »

Quote from: mendip_discovery on August 17, 2021, 11:08:55 am

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 · « **Reply #26 on:** August 17, 2021, 01:24:19 pm »

Quote from: e61_phil on August 17, 2021, 11:27:41 am

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 · « **Reply #27 on:** August 17, 2021, 01:53:00 pm »

Quote from: Anders Petersson on August 17, 2021, 01:24:19 pm

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..

Quote from: Anders Petersson on August 17, 2021, 01:24:19 pm

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.

Quote from: Anders Petersson on August 17, 2021, 01:24:19 pm

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 · « **Reply #28 on:** August 17, 2021, 04:27:52 pm »

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 · « **Reply #29 on:** August 18, 2021, 12:58:52 pm »

Quote from: AaronD on August 17, 2021, 04:27:52 pm

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 · « **Reply #30 on:** August 18, 2021, 09:19:39 pm »

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 · « **Reply #31 on:** January 17, 2022, 11:10:35 pm »

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 · « **Reply #32 on:** January 18, 2022, 05:33:24 pm »

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 · « **Reply #33 on:** January 18, 2022, 08:17:11 pm »

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 · « **Reply #34 on:** January 18, 2022, 10:15:30 pm »

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 · « **Reply #35 on:** January 18, 2022, 10:50:58 pm »

Quote from: krulls on January 18, 2022, 10:15:30 pm

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 · « **Reply #36 on:** January 18, 2022, 10:59:09 pm »

Quote from: krulls on January 18, 2022, 10:15:30 pm

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.

Quote from: krulls on January 18, 2022, 10:15:30 pm

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 · « **Reply #37 on:** January 19, 2022, 04:31:28 pm »

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 · « **Reply #38 on:** January 19, 2022, 04:50:25 pm »

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 · « **Reply #39 on:** January 19, 2022, 09:02:58 pm »

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 · « **Reply #40 on:** January 19, 2022, 10:11:23 pm »

Quote from: krulls on January 19, 2022, 09:02:58 pm

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 · « **Reply #41 on:** January 20, 2022, 03:52:20 pm »

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 · « **Reply #42 on:** January 20, 2022, 06:25:52 pm »

Quote from: krulls on January 20, 2022, 03:52:20 pm

...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 · « **Reply #43 on:** January 21, 2022, 04:06:55 pm »

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

e61_phil · « **Reply #44 on:** February 02, 2022, 07:37:38 am »

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 · « **Reply #45 on:** February 23, 2022, 07:15:18 pm »

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 · « **Reply #46 on:** February 23, 2022, 07:23:35 pm »

Quote from: krulls on February 23, 2022, 07:15:18 pm

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 · « **Reply #47 on:** June 11, 2022, 09:50:55 pm »

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 :

Quote

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 · « **Reply #48 on:** June 12, 2022, 08:25:08 am »

Quote from: French_Nikolas on June 11, 2022, 09:50:55 pm

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 :

Quote
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 · « **Reply #49 on:** June 12, 2022, 12:42:57 pm »

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.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Raspberry Pi for GPIB and data analysis: very easy and fully equipped (Read 15652 times)

Share me