Guide for making a $5 USB-GPIB adapter for EZGPIB

[maxwell3e10]

I have decided to document the process of making a very simple and cheap USB-GPIB adapter that works with EZGPIB, mostly based on existing code, but pointing out a few possible pitfalls.

GPIB connector, $3.78:
https://www.ebay.com/itm/IDC-24-Pin-Male-Centronics-Type-Flat-Ribbon-Cable-FFC-Connector-Adapter/322469299098

The plastic ears need to be cut off, otherwise it fits fine. Use an old computer IDE cable for the IDC connection. By putting 2-3 IDC connectors on a longer ribbon cable it may be possible to connect a few nearby instruments, although I haven't tried it yet.

Microprocessor: $2-3
https://www.ebay.com/itm/ATmega328-5V-16M-For-Arduino-USB-Nano-CH340G-Board-Micro-controller/112867773957

The latest version of Arduino IDE  software works just fine with CH340G chip. I was lucky to get the board for less than $1 shipped, hence the post title.

The ribbon cable wires are separated and soldered directly to the board. Remember the cable numbering goes 1,13,2,14, etc.

For the Arduino software I used Girlando code, because its compatible with Prologix and EZGPIB.
http://egirland.blogspot.com/2014/03/arduino-uno-as-usb-to-gpib-controller.html
If you plan to use Python to talk to the serial interface, there are a few other software options for Arduino Nano available on Github. Also on Github you can find an updated version of Girlando's GPIB6.1 code that implements the SRQ command.

For me the following settings worked: htimeout = 5000;eos=0; eoi=false; eot_enable=true; Also make sure the string returned by the ++ver command contains the string "GPIB-USB" to be recognized by EZGPIB.

For serial interface interaction and debugging I found most useful this terminal program https://www.compuphase.com/software_termite.htm
With a serial terminal test the interface with the following commands:
++addr #
++auto 1
ID?
For real time plotting over serial interface I found this program that can issue a repeated series of commands and plot returned values
https://github.com/ahmedelsayed-93/Serial-Lab

The EZGPIB software won't recognize the driver because it doesn't use CTS/RTS control. It is mentioned on Anders webside http://www.dalton.ax/gpib/ that one can disable this by changing one bit in the program. On the website the bits are not quite right, but he was kind enough to send me the modified executable file. With a hex editor  one needs to change F6 44 24 04 10 0F 95 04   to    F6 44 24 04 10 0F 94 04. Now EZGPIB with recognize the driver. It seems to need to be started twice in the beginning. Check the debug messages if a prologix driver is recognized.

I tested it with an HP3457 meter and a Tektronix scope without any obvious instabilities. Here is a snippet of the code that reads HP3457 as quickly as possible
 

Code: [Select]

EZGPIB_buswritedata(HP3457,'NPLC 10; TRIG HOLD');
EZGPIB_TimeSleep(0.7);
EZGPIB_BusAutoOn;
EZGPIB_buswritedata(HP3457,'?');  //Trigger measurement
repeat
   i:=0;
   repeat
      EZGPIB_TimeSleep(0.01);
      i:=i+1;
   until (EZGPIB_BusDataAvailable or (i>400));     
   answer1:=EZGPIB_BusGetData; 
 
   EZGPIB_buswritedata(HP3457,'RMATH HIRES');
   EZGPIB_TimeSleep(0.1);     // For  reading high resolution register
   answer2:=EZGPIB_BusGetData; 
   
   EZGPIB_buswritedata(HP3457,'++read');     //read empty line that seems to appear
   
   EZGPIB_buswritedata(HP3457,'?'); //start next cycle
 // *** processing and saving data

until EZGPIB_KbdKeypressed;



[bitseeker]

Hi Maxwell. Thanks for putting together an up-to-date summary for building and running one of these. It's been a while since the last related thread. I wasn't aware that Girlando had added SRQ, for example.

[ebastler]

Is anybody aware of an Arduino-ish board which would be small enough to install inside the metal hood of a typical Centronics plug? (And which has USB and a sufficient number of available I/O pins for the GPIB interface, of course?)

This form factor looks neat, but it's a Cortex M0 board, which would probaby require a major software re-write? 
https://www.ebay.com/itm/Nerdonic-Exen-Mini-32Bit-48MHz-256KB-32KB-Smallest-Arduino-Comp-Board/183290650478

[TurboTom]

@ebastler

the Exen Mini has insufficient I/O to run a GPIB without additional hardware. Moreover, for a GPIB emulation you would be looking for logic that will handle 5V.

[ebastler]

the Exen Mini has insufficient I/O to run a GPIB without additional hardware. Moreover, for a GPIB emulation you would be looking for logic that will handle 5V.

Thanks TurboTom. The Exen board was mainly meant as an illustration of the form factor I was hoping to find. Are there any ATmega328 boards around in a similar size (and with a couple more I/Os)?

[kutte]

maxwell3e10

 Also on Github you can find an updated version of Girlando's GPIB6.1 code that implements the SRQ command.

where on github do I find this enhanced version? could you please provide a link?
thanks Kutte

[maxwell3e10]

I did not post a link because Girlando's code has no-derivative license. If you search on Github for GPIB USB Arduino, its one of a few hits.

[kutte]

got it. Thanks Kutte

[sundance]

@maxwell3e10:
Thanks a lot for the corrected patching sequence for EZGPIB!
And for the hint to find an updated GPIB61.ino...

[gtmuk]

Hi Maxwell,

I'm in the process of building the same thing, using the Atmel Mega 328p board. Is the wiring the same as on Girlando's design i.e.

 A0   GPIB 1
   A1   GPIB 2
   A2   GPIB 3 
   A3   GPIB 4
   A4   GPIB 13
   A5   GPIB 14
   4    GPIB 15
   5    GPIB 16
   12   GPIB 5
   11   GPIB 6
   10   GPIB 7
   9    GPIB 8
   8    GPIB 9
   7    GPIB 11

I guess the digital IO's are labelled "D.." on that board. If the 6.1 version uses SRQ which pin does this line go to?

Sorry for the late addition to this thread, but I've just found it...

Thanks!

[maxwell3e10]

SRQ (GPIB pin 10) goes to pin 2 on the Arduino

[coromonadalix]

I saw the girlando page

Noob questions about gpib, never used this interface before

Is this gpib would or could be compatible with  Ex: 34401a, 3478a, sig gens psus  etc ...    in the Hp / Agilent family

I think the smallest 328 board is the mini ??    arduino mini  ??

[bitseeker]

coromonadalix,

There are two parts to the typical GPIB setup to keep in mind: electrical (pins, signals, etc.) and software. The electrical part follows standards such as IEEE 488, 488.1, and 488.2. Generally, a conformant GPIB interface works with many devices and brands. However, some interfaces (often less expensive ones) may not provide enough current to drive many devices on the same bus. Nevertheless, even they should work with one to approximately three devices.

The software side can be more problematic. This thread, for example, results in a GPIB interface that works with software, such as EZGPIB, that knows how to talk to a Prologix GPIB interface. Other GPIB interfaces, such as HP/Agilent/Keysight and National Instruments, have drivers that are compatible with the VISA software standard. Thus, if you're using existing software (i.e., not writing your own), you need to check what its software requirements are and that your GPIB interface satisfies those requirements with compatible drivers/libraries/etc.

The Arduino Pro Mini was the tiny board, but arduino.cc has discontinued it. There are still plenty of similar compatible boards in the wild. The current tiny 328-based board is the Arduino Nano.

[TheNewLab]

This is an excellent project !!
Any suggestions for which better software to use? from a GUI perspective?

[coromonadalix]

thks Bitseeker for all the infos,  great project

I have an Arduino uno, teensy 3.1 and a mega2650 to try   

I saw other arduino projects, one of them has an driver chip to provide buffering and protection ??

[bitseeker]

The buffer chip(s) provide the current required to drive a longer bus with more devices attached. If you're just using one or two (e.g., DMM and power supply), it may not be necessary. As with most things, it depends on your requirements.

[gtmuk]

Hi All,

I've built the converter based on the Atmel Mega 328p board, and it kind of works - at least there doesn't seem to be a hardware problem.
But I've a hard time getting it to work reliably with EZGPIB. The problem seems to be timing related - the instruments (2 Solartrons DMMs and a Prema 5017) don't always respond as expected, even if they are connected one at a time. The main influence factor seems to be the handshake timeout (read_tmo_ms). This has to be "right" in relation to the "speed" at which commands are sent. So in one instance I've got to use 10000 ms for the timeout and at the same time insert delays of about 10 s into the EXGPIB code.
Sometimes the instruments don't react to commands, and sometimes the replies (readings from the instruments) don't show up.

The funny thing is that it seems to work very reliably through a serial monitor (Termite). Note that the Termite still goes through the USB, same port as the EZGPIB comms.

Has anybody found a way to "tune" the settings in such a way that EZGPIB can be used in a predictable manner?

I should say that I do have a Prologix converter, too, and that this works perfectly with the Solartrons and the Prema. It's just that I have a need for more than 1 such setup, hence the attempt to use the Arduino approach.

Thanks,
Thomas.

[coromonadalix]

you mean this line in the gpib6.1 ino  ??

int htimeout = 200;       // Handshake timeout. Also known as read_tmo_ms. Its actual value has to be found by
                                  // trial&error depending on the actual application.

With your prologix adapter, is there a way to know the time out response delay

IS this software can be useful ?  gpib tool kit : http://www.ke5fx.com/gpib/readme.htm

EDIT :  just found theses guy :
https://www.sparkfun.com/products/12640
https://www.buyapi.ca/product/arduino-pro-micro-5v16mhz/

[gtmuk]

Hi again,

The read_tmo_ms of the Prologix is set to only 500 ms. This always works fine, I've never altered that. But the same setting doesn't work with the Arduino board and SW. The DMM often doesn't respond within 500 ms (at 7 or 8.5 digits) and without delays in the EZGPIB code the commands come too fast. So there must be some issue with the handshake that I'm not understanding.
I've overcome it by carefully tuning read_tmo_ms to allow for the longest response time of the DMM, and then delaying each subsequent bus command until the read_tmo_ms have elapsed.

I'm no expert on this but it feels like the Prologix board does proper handshake through the lines or termination characters whereas I seem to rely on careful timing. Would be interested if somebody can shed some light at this.

By the way the reason there are no issues through the serial monitor is simply because I was running with a long enough timeout setting, and entering commands so slowly by hand that the timeout had elapsed.

Unfortunately the Prologix.exe from ke5fx doesn't seem to work with the Arduino board either - not too surprising since the firmwares are totally different.

One other observation, probably clear to everybody but me: Once you've hex-edited EZGPIB to work with the Arduino board it doesn't work with the Prologix board anymore. So you'll need to keep an unedited copy - no real issue.

T.

[coromonadalix]

Could it be an hardware id in the prologix adapter,  an device enumeration id ?

The prologix is based on atmega164 with an ftdi 245 ??  surely something could be done with an more powerful atmega chip instead of the 328 , a 1284 ??

[maxwell3e10]

I had setup  htimeout =9999, but it is mainly needed for very slow commands, like meter reading with NPLC=100. The program shouldn't rely on the timeout.
For sending commands I would use something like this:
EZGPIB_BusAutoOff;
EZGPIB_buswritedata(HP3457,'DISP OFF;LOCK ON;BEEP OFF');
EZGPIB_TimeSleep(0.7);
EZGPIB_buswritedata(HP3457,'DCV 3');
EZGPIB_TimeSleep(0.7);
It seems putting too many commands in one line or doing them too quickly can cause problems.
For reading, I would use something like this
EZGPIB_BusAutoOn;
EZGPIB_buswritedata(HP3457,'?');   
repeat
   EZGPIB_TimeSleep(0.01);
   until EZGPIB_BusDataAvailable;     
answer1:=EZGPIB_BusGetData; 

One can also use:
EZGPIB_buswritedata(HP3457,'ERR?');
EZGPIB_buswaitfordata(HP3457,answer,1.0);   
In this case 1.0 specifies the timeout. But this command seems to be slower.

[gtmuk]

I've now achieved partial success, good enough for what I need, pretty much along Maxwell's lines:
Basically I can't get EZGPIB_buswaitfordata() to work, try as I might. But  EZGPIB_BusDataAvailable and EZGPIB_BusGetData work fine, as long as the commands are sent slow enough to be outside the htimeout window (which I now run at 500 ms). With this I can live as I am reading the DMMs at a pedestrian rate. And of course the inserted delays have to allow the DMMs to respond.
I can also confirm that 2 DMMs in the bus on one common Arduino board work fine. I guess there would eventually be a limit when the absence of line drivers stops the fun.
Considering the low cost of the boards and available software I would say this is still a worthwhile option keeping GPIB instruments alive, if you're prepared to experiment a bit. Having access through the serial monitor helps a lot, you can try out the commands and see what's going on without having to go through EZGPIB. Once you've figured the gist of it EZGPIB will do its usual wonder, thanks to Ulrich Bangert's efforts.
I'll certainly build a few more of these, and perhaps people with more programming skills than me will keep tweaking the Arduino code. Thanks to all who have contributed over the years!

[WaveyDipole]

Having recently done some work with the Arduino as a GPIB adapter recently, I have also run into the RTS/CTS handshake problem with KE5FX GPIB Configurator and EZGPIB. Assuming that the correct version strings have been set, my finds were as follows:

An Arduino board with the 16U2 embedded FTDI UART works fine with KE5FX although it is still a bit erratic with EZGPIB, often failing on first attempt. If you have a board that uses the CH340G UART, then it will not work at all with either program. I have noted the software workaround for EZGPIB in the opening post, but there is also a hardware workaround on boards with the CH340G chip. This involves connecting pin 9 to pin 14 on the CH340G to loop back the RTS signal to the CTS pin and send it back via USB to the host. That gets around the lack of CTS response from the Arduino with the CH340G chip and the KE5FX Configurator will now respond as expected. The same workaround is not possible and not necessary with the 16U2 (FTDI) chip.
With EZGPIB there is also an issue with timing, since connecting to the serial port prompts a reset of the Arduino board. On restart, the bootloader is run and first waits for a sequence of bytes indicating that the IDE is trying to upload a sketch. If it receives them, then it proceeds to accept the upload. If it does not receive the sequence, then once the wait period has expired program execution is passed to the compiled sketch. This is what allows a sketch to be uploaded easily via USB instead of messing with the reset button. However, the delay that results from this process also causes a problem with detection in EZGPIB. Since EZGPIB does not wait before checking the version string, the board is not detected the first time around. I can only speculate as to why it is then detected the second time around. Perhaps with the reset still being in progress, the second reset is ignored and reset then completes within timeout. Try it again a couple of minutes later and it fails again.  Whatever the case, the workaround is to add a 10uF capacitor between the RESET and GND pins, taking care to ensure that the negative lead goes to GND. This will "block" the reset signal. Now, when something connects to the serial port, there is no reset and no delay and EZGPIB will now reliably detect the board. Of course, with the capacitor connected, the Arduino can no longer be programmed via USB, so to program, the capacitor has to be removed again. Add a switch in series with the capacitor would perhaps provide a "run" and a "program" mode.

Please note that the KE5FX GPIB Configurator requires a somewhat longer version string, namely “GPIB-USB version M.NN” where M is a major and NN a minor version number that is at least 2.xx and up to 4.26. Settings are enabled according to the functions of the hardware on various versions. Anything equal to or above 4.26 is treated as the latest version and all functions are enabled. Emanuele mentions that he ‘had to force “version 6”’ but anything above 4.26 seems to work fine. I have successfully used the string “GPIB-USB version 4.99”.

Incidentally, for the last 3 months or so, I have been working on an updated GPIB firmware for the Arduino. It was originally inspired by Emanuele's code and implements the same pin assignment scheme, but is an almost complete re-write. The remaining controller functions have been implemented, SRQ and REN lines are now fully supported and device mode has been added. The ++lon command does not work yet and secondary addressing has not yet been implemented, but the project is nearing a stage where it can be released (with the original author's permission) which I hope to do in the near future.

[jimmc]

Using a 10uF capacitor on the reset pin may damage to the reset switch if it is pressed, I used a 100ohm resistor  connected via a jumper to allow programming when removed.
see https://www.eevblog.com/forum/testgear/gpib-interface-(ieee488)/msg1148751/#msg1148751.

I look forward to seeing your new code.

Jim

[WaveyDipole]

My code has now been posted here:

https://github.com/Twilight-Logic/AR488

Any feedback as well as suggestions for improvement are welcome and can be posted here:
https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg2191794/#msg2191794