open source GPIB adapter

[caiser01]

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.

I've been running R&S VISA on Linux on the Raspberry Pi with zero issues. Like the Windows version, the Linux version of R&S VISA is small, lightweight, and doesn't drag you into any sort of package dependency hell. The only quirk I've encountered is needing to explicitly reference the R&S VISA library in my Python scripts in order to keep pyvisa from automatically wanting to grab pyvisa-py as the backend, but it's pretty easy. I just have this at the top of all my Python scripts for GPIB:

Code: [Select]

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()

[alm]

What's the advantage of R&S VISA over PyVISA-py, which requires even less setup?

[dazz1]

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?)

[alm]

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.

[dazz1]

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.

OK so I should just follow the instructions for PyVISA-py.

[caiser01]

What's the advantage of R&S VISA over PyVISA-py, which requires even less setup?

The xyphro adapter presents itself to PC as a USB device and in PyVISA-py, there are several VISA functions that are not implemented for USB. These include clear(), read_stb(), and assert_trigger() all of which can be necessary to take full advantage of an instrument's remote programming capabilities. read_stb(), assert_trigger(), and the various "event" functions in particular are often necessary to get the fastest possible communication with an instrument.

To install R&S VISA on the Pi on Linux, all I had to do was download it and run:

Code: [Select]

sudo dpkg -i rsvisa_5.12.9_raspios_buster_arm64.deb
Running the installer on Windows or Mac is pretty quick too, so I would argue the setup effort is minimal.

R&S VISA also provides the Tracer app, which is super handy for debugging. Just open it and start monitoring in the background while your own application is communicating with the instrument, and you can watch all the raw traffic between your application and the instrument. Great way to track down issues in your GPIB command sequences, especially for the quirkier instruments.

[Nx-1997]

Well I finally decided to benchmark my GPIB adpaters since Xyphro released a new firmware. The results shows the capture time (s) for reading a waveform from my tek scope. The new firmware is much faster but not as fast as the Agilent 82357B. The AR488 is the slowest but also the only one not requiring any special drivers or software.

Full results discussion are here: https://github.com/xyphro/UsbGpib/discussions/47

[caiser01]

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 

[dazz1]

Hi
I have started to learn Python and Py VISA to write code to run my mostly ancient instruments with GPIB.  I have already hit problems writing code that I am sure others have already solved.  I have started a new thread here:
https://www.eevblog.com/forum/projects/problems-writing-code-for-gpib-py-visa/new/#new as a sort of mini-forum.

[coromonadalix]

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 

at :  https://github.com/xyphro/UsbGpib

[dazz1]

Hi
Just a tip.
I spent the day assembling 4x usb-gpib adapter. 
My first adapter assembled a few weeks ago had problems with bad joints and solder bridges.  I blame it all on the cat.

This time I pre-tinned the pins for the usb-c connector and the matching pads.
I also pre-tinned the QFN pads and pcb pads.

I smeared solder across the earth/heat pad on the QFN.

This left a Goldilocks amount of solder for the joints.  All good joints and no excess solder to clean away.  The cat is sleeping peacefully.

[dazz1]

Hi
A question for those with experience debugging gpib.  Is it still useful to have a breakout board to read the gpib signals??

The reason I ask is because I have HP54645D scope with 16 channel digital logic inputs like this one  https://metalab.at/wiki/Datei:HP54645D.jpg.  If I make a gipb breakout board, I can plug the flat cable into the scope and board.  No fiddly probes.
The same board could be used with a HP logic analyser because they use the same cable.

[pdenisowski]

Hi
A question for those with experience debugging gpib.  Is it still useful to have a breakout board to read the gpib signals??

I just bought a commercially made GPIB breakout board.  Am planning to use it this week to debug / analyze some GPIB traffic.

https://tinyurl.com/2s499tar

(Sorry, tried to post link to the pics here on EEVblog and it keeps failing, so posting a shortened link)

[Kean]

Can certainly be useful if you need to diagnose weird GPIB issues or debugging your own interface
I made up one of these by Jason aka cellularmitosis

https://github.com/pepaslabs/gpib-spy

[dazz1]

Hi
Well it looks like I will be making a break out board, but not like either of the linked designs.

I will make use of the connectors I have in the photo.
I got the Centronics gpib connectors from Aliexpress because they are dirt cheap.  I purchased the HP logic analyser compatible connector to see if it would fit.  It does, that gave me a solution looking for a problem.
I will design a board that will connect directly to an HP logic analyser, that I don't have, or my HP 54645D mixed signal scope that I do have.
The logic probes designated for the HP54xxx series scopes have the probes integrated with the flat cable.  They are rare an expensive. 
I purchased the cable  and probe set that plug together. Easier to find, cheaper and more versatile.

Along with the Centronics connectors, and HP compatible connector I will include pads for a separate header to make it easy to probe individual lines, if ever needed. Probably a feature I would never use but extra pads are a zero cost. 

I will be able to save a configuration in the scope, and just plug and play the break-out board.  The board will still be usable for someone without a logic analyser. 

[dazz1]

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.

[caiser01]

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.

I do have access to a copy of IEEE 488.1 and regarding grounding, it says:

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.

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.

[caiser01]

For completeness, it may also be worth noting the maximum resistance per meter for each conductor and insuring the design of your breakout doesn't cause a violation of these requirements:

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 Ω

[dazz1]

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.

The board by itself is passive, but it will be connected to the logic analyser I don't have, or my HP 54654D logic input. I am including a header that will allow the cable to be plugged into the board, no probes.  The probe adapter for the cable has one earth.  So I can separately route all of the individual earths that are supposed to be separate in the cable, but I still need an earth for the scope.   The most logical gnd being the Logic gnd at pin 24.  Does that sound right? 

[dazz1]

After a little more thought:
The intended use is to plug-in directly to the subject equipment.  It is very likely that the equipment will have all earths connected.  Repeating that connection at the gpib panel connector is probably not going to be enough of an issue to stop the breakout board doing the job it needs to do.

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.  The exception might be the shield.  Somewhere I read this should be linked to the other earths by a 1M resistor.   Maybe to keep the dc floating volts within reasonable limits but that is not a convincing argument.

I could include a DIL2x8 header to selectively link earths to a main ground but it would actually be less work to produce a new Mod 2 pcb design. 
So the plan is to connect all the grounds together, except the shield.  I will run that straight through with a Fit-For-But-Not-With option for a smd resistor, just in case. 
If there is a problem, I will design a new pcb.

[pdenisowski]

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. 

The average engineer working in test and measurement in the 1980s/1990s would either (a) have bought commercial off-the-shelf GPIB adapters and cables and not needed the spec, or (b) would have the spec if they were actually developing GPIB devices.  Ask me how I know

That said, I think this is a fantastic project and am very excited to see how it turns out.  Thank you for doing this!

[dazz1]

Hi
Given where you work, I would have thought the developers already have breakout boards.
Anyway, attached are my drafts. 

Unlike other breakout bds I have seen, my one has a connector that conforms to the HP pseudo standard 40pin Logic Analyser cable. This board will plug directly to my HP scope  that I have, or any HP LA I don't own.  No messing around with probes.

The board will be self documenting.  I am going to add text to the lower silkscreen to show the 40 pin connector signals.  Already done that for the header. 

The header has the same pin-out but exposes the signals and allows for jumpers to be fitted.  Specifically, one use case would be to connect a control signal to the LA CLK.  It also means that someone who does not have a suitable LA type instrument can probe the signals with this board.

I am interested in any feedback to improve the design.

[pdenisowski]

I am interested in any feedback to improve the design.

Frankly, I like it just the way it is - a big improvement over what I've seen so far for GPIB breakout boxes.

[dazz1]

Hi
I have polished the design. 
Getting pcb's made and buying parts with MOQ's means I will end up with 5 of these, when I only need one.

[Kean]

I believe the intent was that pin 12 should be connected to the cable shield (chassis ground) and not to logic ground.
Pin 24 is the primary logic ground, and pins 18-23 are nominally logic ground but are actually specified as paired with the signal on the pin above (6-11).

Practically all devices I've seen connect pins 18-24 together, and only some also include pin 12 connecting the this common ground.
As an example, schematics of Keithley 199 have pin 12 connecting to chassis, and there is a 1M resistor and 10n capacitor between chassis and logic ground (with optional jumper).

I doubt any of this will make much difference except with very long cables and multiple instruments.