I would like to get my little old Linux Asus eeePC running pyvisa. What do you suggest, and in what order should I install? NI, R&S ?I found installing a commercial VISA stack a pain on Linux. Especially maintaining it through OS upgrades. I'd also research what hardware they support. I know NI-VISA doesn't support NI GPIB-USB devices on Linux kernel versions from the last 15 years or so. I don't know about USBTMC.
I would use PyVISA-py as backend. This integrates much better with Linux and doesn't require any kernel modules or daemons to run.
from sys import platform
if platform == "linux" or platform == "linux2":
# Linux
rm = pyvisa.ResourceManager("/usr/lib/librsvisa.so@ivi")
elif platform == "darwin":
# macOS
rm = pyvisa.ResourceManager("/Library/Frameworks/RsVisa.framework/RsVisa@ivi")
elif platform == "win32":
# Windows
rm = pyvisa.ResourceManager()
What's the advantage of R&S VISA over PyVISA-py, which requires even less setup?
I had a look at your launchpad page. I see you are maintaining GPIB firmware, kernel and user packages.
Can you please explain what each package is for (the use cases?)
I had a look at your launchpad page. I see you are maintaining GPIB firmware, kernel and user packages.
Can you please explain what each package is for (the use cases?)That isn't necessary to use with the adapter discussed in this topic, which uses USBTMC. As you can read in the PyVISA-py documentation, it just needs libusb for this.
The packages in my signature is for with commercial USB and PCI(e) GPIB interfaces like those made by Agilent, Keysight, NI etc. Also clones, as far as I know. There are kernel drivers, the user space libraries so native (C) applications can talk to them, and Python bindings so Python can talk to them. These packages would allow you to use for example an NI GPIB-USB-HS interface with PyVISA-py.
What's the advantage of R&S VISA over PyVISA-py, which requires even less setup?
sudo dpkg -i rsvisa_5.12.9_raspios_buster_arm64.deb
I tested xyphro's new release candidate firmware today. Very solid so far. My instruments are old and slow enough that I'm not really seeing the improvements in read/write speed for data but I *did* see a speed improvement in reading the status byte. Reading the status byte of my HP3478A is 250ms faster with the new firmware than the old firmware
Hi
A question for those with experience debugging gpib. Is it still useful to have a breakout board to read the gpib signals??
Hi
Looking at the detail of the gpib cable standard to apply to my breakout board, the pin-out includes a shield ground plus signal grounds.
My question is: Should the shield ground be connected to the signal grounds?
The IEEE 488.1 mechanical specification costs a $squillion ( = $USD391.00) so not looking there.
5.6 Ground requirements
The overall shield of the interconnecting cable shall be connected through one contact of the connector to frame (safety earth) to minimize susceptibility to and generation of external noise.
WARNING—Devices should not be operated at significantly different frame potentials. The interface connection system may not be capable of handling excessive ground currents.
It is recommended that the ground returns of the individual control and status signal lines be connected to logic ground at the logic circuit driver or receiver to minimize cross-talk interference transients.
5.7 Cable characteristics
5.7.1 Conductor requirements
The maximum resistance for the cable conductors shall be, per meter of length
a) Each signal line (for example, DIO1, ATN) 0.14 Ω
b) Each individual signal line ground return 0.14 Ω
c) Common logic ground return 0.085 Ω
d) Overall shield 0.0085 Ω
Based on that, I would answer your question with a 'No'. It sounds like the intent is to connect the cable shield to the safety earth ground of an instrument or controller (assuming it has a safety earth ground).
In your case, since this is a breakout board for debugging purposes and is essentially passive, like a cable, I would say just make sure the shield ground connects through the breakout from one GPIB connector to another. Do not permanently connect any grounds together on the breakout that would normally run separately inside a cable.
Also I suspect the average 1980's/90's engineer would not have paid for the standard and would likely simply connected all of the earths together.
I am interested in any feedback to improve the design.