AR488 Arduino-based GPIB adapter

[eliocor]

it surely is a "Pro Micro" and it must be recognized as a "Leonardo".
Please take care that, even if correctly programmed, it will not be recognized by EZGPIB. 

[wkb]

Right... when programmed with the 'stock'  AR488 code and with AR488_CUSTOM left undefined it does work with the HP3478A.exe tool.  It now happily reads data from the HP meter.

Sofar so good.

Wilko

[wkb]

it surely is a "Pro Micro" and it must be recognized as a "Leonardo".
Please take care that, even if correctly programmed, it will not be recognized by EZGPIB. 

Sorry, got confused earlier: indeed EZGPIB does not seem to work using this particular 'Leonardo' Arduino.
I have patched the EZGPIB to skip the CTS check. No luck.

Wilko

[eliocor]

It seems no one who reads this thread is also the owner of an original Prologix USB interface. In a previous post https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg3212484/#msg3212484 I asked for the output results (debug) when EZGPIB starts, but with no avail.

[wkb]

Unfortunately I cannot help you there. The other AR488 which runs with a FTDI cable
works without complaints on EZGPIB. But you already knew that. 100$ question is what difference
makes EZGPIB not work with the Leonardo

Wilko

[kutte]

these Leonardos (e.g. arduino pro micro) use a so called CDC USB-interface that does not provide a CTS signal.
So no joy, sorry for that Kutte

[wkb]

these Leonardos (e.g. arduino pro micro) use a so called CDC USB-interface that does not provide a CTS signal.
So no joy, sorry for that Kutte

Hm, but a patched EZGPIB (i.e. should no longer care about CTS) also does not work. 🤔

But I have two working AR488 with FTDI cables that work just fine so I am happy 👍🏻😁😁

Wilko

[WaveyDipole]

Unfortunately selecting a custom layout by #define AR488_CUSTOM results in a compile error for the serial port 

Like so:
215:46: error: cannot convert 'Serial_*' to 'HardwareSerial*' in initialization

   HardwareSerial *arSerial = &(AR_SERIAL_PORT);

Right... when programmed with the 'stock'  AR488 code and with AR488_CUSTOM left undefined it does work with the HP3478A.exe tool.  It now happily reads data from the HP meter.

Sofar so good.

Wilko

As has already been mentioned, on 32u4 based boards, a CDC (emulated) serial port is used rather than a hardware port. Therefore, if the custom layout is used with a board that uses a USB CDC serial port, then under #ifdef AR488_CUSTOM section (starting line 32),  the line #define AR_HW_SERIAL needs to be commented out and #AR_CDC_SERIAL needs to be uncommented.

Having said that, as you have discovered, the board in the photo is a "standard" Micro Pro clone and works without resorting to the custom layout. The board option to select for these within the IDE is 'Arduino Micro'.

It seems no one who reads this thread is also the owner of an original Prologix USB interface. In a previous post https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg3212484/#msg3212484 I asked for the output results (debug) when EZGPIB starts, but with no avail.

That would certainly be useful if someone reading this has a Prologix interface.

Hm, but a patched EZGPIB (i.e. should no longer care about CTS) also does not work. 🤔

But I have two working AR488 with FTDI cables that work just fine so I am happy 👍🏻😁😁

Wilko

I investigated this somewhat a while back and the issue is, I beleive, one of timing. It is similar to the problem with the CH340 chip where the board reboots when you make a serial connection and there is a delay while the bootloader and then the sketch is re-loaded. Because there is no hardware RTS/CTS handshaking, EZGPIB has "moved on" and completed auto-detection before the re-boot cycle is complete and it fails as a result. With CDC Serial, the delay is not caused by a reboot, but I think ocurrs while serial emulation kicks in and the port is made available. By this time EZGPIB has checked for a resonse and having not received one, fails the autodetect. In my tests I simply saw a null response from the Arduino in response to the ++ver command. While for boards with the CH340 chip there is a hack to prevent the re-boot which solves the delay problem, the same cannot be applied to an emulated serial port. EZGPIB would need to wait until the serial port is ready or at least re-try after a short delay before attempting to read it. I need to do further research, but from what I have discovered so far, Arduino has no method to send the CTS signal over a CDC USB connection.

[l3VGV]

Im trying to make pro micro to work, with no success.

Board is same as in wkb post
https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/?action=dlattach;attach=1172536;image

First i tried to flash hex file AR488.micro.32u4.hex, no luck

Code: [Select]

avrdude: erasing chip
avrdude: reading input file "C:\1\AR488.micro.32u4.hex"
avrdude: writing flash (32730 bytes):

Writing | ################################################## | 100% 2.92s

avrdude: 32730 bytes of flash written
avrdude: verifying flash memory against C:\1\AR488.micro.32u4.hex:
avrdude: load data flash data from input file C:\1\AR488.micro.32u4.hex:
avrdude: input file C:\1\AR488.micro.32u4.hex contains 32730 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.87s

[b]avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x70ff
         0x9a != 0x98
avrdude: verification error; content mismatch[/b]
Dont know how to change efuse for brownout on pro micro without external programmers. Builtin one cant do it it seems.

Well, it in device manager as com14(or Arduino MICRO on my laptop), but if i use putty there is no response. Two LED is always on, one blink if i write to terminal(one close to pin labeled 7).

***

second attempt was to flash board from Arduino IDE. Board option is set to "Arduino/Genuino Micro"
Just unziped, changed Board option and upload, no changes made in sources.
No errors.

Code: [Select]

avrdude: reading input file "AR488.ino.hex"
avrdude: writing flash (19714 bytes):

Writing | ################################################## | 100% 1.72s

avrdude: 19714 bytes of flash written
avrdude: verifying flash memory against AR488.ino.hex:
avrdude: load data flash data from input file AR488.ino.hex:
avrdude: input file AR488.ino.hex contains 19714 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.38s

avrdude: verifying ...
avrdude: 19714 bytes of flash verified

avrdude done.  Thank you.
But putty do not get any response from board anyway. LED is blinking if i type.

Board is connect to USB, is it supported or with pro micro usb-ttl adapter have to be used?

[eliocor]

if you are using the arduino IDE to compile the software you have to choose board type: [Arduino Leonardo]

[l3VGV]

Ok, done that.
Firmware HEX size exactly the same.
Device ID and com number changed, both LED is normally OFF, and one blink while i type into terminal. But no reply from it anyway. 

Pins like A2, A0, D3 etc always high, is it supposed to be like that? No reaction on terminal on any of them. Always 1.

Made simple sketch that toggle all pins 1 and 0, works fine.



Flashed board back to arduino micro.

Now if i connect to board with putty while it in bootloader mode, terminal works fine, can see characters.



*
Ok, bought one more board. That new one somewhat working. I can get atleast some replies from my 34401. What wrong with previous one, no idea. Bad china fake?


putty

> *IDN?

    > ++read

    HEWLETT-PACKARD,34401A,0,5-1-1
                                  gpibReadByte: timeout waiting for DAV to go LOW
Bytes read: 32
Timeout waiting for sender!

    > MEAS:VOLT:AC?
    > ++read

    +1.47722700E-03
                   gpibReadByte: timeout waiting for DAV to go LOW

    Bytes read: 17
    Timeout waiting for sender!

Can see no difference with "Leonardo" or "Micro" board option in IDE, except that leonardo status LEDs always off and turn on when indicating typing and replies, and Micro is inverted - always on, and turn off.


**

Construction.

Connector is Connfly CENB-24M (DS1039 24ML0), Centronic-24
Case Connfly DPT-25C (DS1045-25 AP1L)

It almost perfect fit.  Well, almost. Ok to begin with.
See pictures.

[WaveyDipole]

My initial thought was to increase the value of ++read_tmo_ms, although that does not seem to be the issue here as the read process appears to have been completed. The other possible explanation is that the interface has not received the expected termination characters and assumes there is more data to come but the instrument is not sending any, therefore the read process times out. Looking at the HP34401 manual, the termination character over IEEE488 is just <nl>. By default the interface looks for CR+LF. You could try setting ++eor 2 which will check for LF (<nl>) only.

With regards to the first board, GPIB signals are HIGH when un-asserted and LOW when asserted. In controller mode (++mode 1) REN is asserted and therefore LOW, but in device mode (++mode 0) it is set to INPUT_PULLUP and therefore HIGH, expecting the controller to pull it low. On the other hand, A0 and A2 are mapped to data lines DIO1 and DIO3. The line state would be LOW to indicate that a bit is set but HIGH when the bus is idle. Therefore A0 and A2 being HIGH when the interface is idle would be normal. I am not sure why the serial port did not work.

The binary image is compiled with bootloader included and enables the USB CDC serial port by default at 115,200 baud, although with CDC ports the speed should be irrelevant. I had thought to include these binary images as a courtesy, but using the IDE and compiling from source is the recommended method.

[l3VGV]

My initial thought was to increase the value of ++read_tmo_ms, although that does not seem to be the issue here as the read process appears to have been completed. The other possible explanation is that the interface has not received the expected termination characters and assumes there is more data to come but the instrument is not sending any, therefore the read process times out. Looking at the HP34401 manual, the termination character over IEEE488 is just <nl>. By default the interface looks for CR+LF. You could try setting ++eor 2 which will check for LF (<nl>) only.

"++eor 2" did the trick for 34401. Sorry for the fuss. I have two instruments with GPIB right now, hp 34401 and escort edm-3150, escort works totally fine without any adjustments. And with my little knowledge of GPIB, wrong assumptions were made.

GPIB seems to be complex and each vendor do whatever. (after alot of googling, YouTube kicked in with that recommendation )

> ++eor 2

Set EOR to: 2

> *IDN?

> ++read

HEWLETT-PACKARD,34401A,0,5-1-1
                              Bytes read: 31

>

With regards to the first board, GPIB signals are HIGH when un-asserted and LOW when asserted. In controller mode (++mode 1) REN is asserted and therefore LOW, but in device mode (++mode 0) it is set to INPUT_PULLUP and therefore HIGH, expecting the controller to pull it low. On the other hand, A0 and A2 are mapped to data lines DIO1 and DIO3. The line state would be LOW to indicate that a bit is set but HIGH when the bus is idle. Therefore A0 and A2 being HIGH when the interface is idle would be normal. I am not sure why the serial port did not work.

Current hypothesis - board was damaged by me Its winter here, very cold and alot of static(i like wool sweaters).

[WaveyDipole]

Glad that got it sorted.

You are correct that each device/vendor do their own thing. GPIB, like Ethernet or WiFi provides the connectivity, but its up to the application to interpret and send the correct instrument data. After all, each instrument has its own characteristics and they do vary wildly. A DMM is a very different thing from a Spectrum analyser or signal generator so each will have their own peculiar set of commands and data formats.

It is always possible to damage a part on a board by static discharge and its a bit of a "Russian routlette" as to whether it actually happens or not if one does not take precautions. Of course Russian winters are much colder than ours here in the UK, so I expect more wool required....

[Hydron]

Just got my first GPIB instrument (Keithley 236), and found this project which looks like the perfect way to get basic connectivity (enough to access the GPIB-only cal routine, do some light datalogging etc) without spending the earth.

I am going to use artag's compact design as I just need the one instrument connected and want to avoid extra cables, and was wondering if anyone had a spare adapter PCB (this one: https://oshpark.com/shared_projects/HrS1HLSE) they could chuck in an envelope to send me if I pay postage? Mainly asking to avoid an order of 3/5/10 pcs when I only need one, given others likely already did that and have spares. No worries if nobody is keen, will just get it from OSHPark or in my next Chinese board order. Would be to London, UK, and I'm not in any particular rush.

Finally thanks to everyone who has worked on this project - looks like it'll make the GPIB interfacing task much easier than I expected, and for under 20 quid at that!

Edit: eliocor has offered to send a board, as per his earlier post that I missed on page 24 - cheers!

[Sprock]

Hi there
in request from eliocor here the Prologix Print out.
May bee in wrong thread. So please excuse.

best regards
sprock

[eliocor]

Tanks a lot!
Now I will try to identify in the disassembled code the different steps when an AR488 (micro pro) is connected.

[AtlanticSurfer]

First of all, kudos to all the members contributing to this project and to WaveyDipole in particular, your detailed responses to questions and the thoroughness of the manual let alone the firmware itself are remarkable.   Thank you Artag for the board and code for it, it seems very popular – hope I can get it working.  I’d like to congratulate maxwell3e10 on the creation of the wireless contraption – I like that 😊.

I subscribed to this post March 2019 and finally decided to give building one a go – I have very little experience with this kind of stuff.  I’ve assembled one but testing has not gone as I’d wished so I’m hoping for some help to get over the line.

I’ve been using an Agilent interface and Agilent software and am pretty clueless when it comes to Prologix/NI.  My goal is to have this interface work with Test Controller software being developed by eevblog member HKJ (Blog Topic: Program that can log from many multimeters.) but at the moment I’m unable to communicate with my 34401a’s, they just time out.  I don’t know if there is something wrong with my interface or if I’m not getting the syntax of commands correct or if the serial connection setup needs modified - serial vs emulated vs virtual vs socket connection - this stuff baffles me.

Could someone suggest some (syntactically correct) commands that I could type into the Arduino IDE serial monitor or into PuTTY to check for a response?  The device responds to ++ver & ++addr but if I try *idn? It just times out.

Do I need to adjust any of the default parameters?  Further detail below.


Firmware: AR488 GPIB controller, ver. 0.49.12, 11/01/2021
MCU: Pro Micro, 32u4, 5V 16MHz (tested via raw).

With MCU mounted on Artag V3 PCB continuity tests indicate the MCU pin arrangement matches the arrangement detailed in the AR488 manual for the Micro (not Leonardo) except that GPIB pin 12 connects with PCB shield pad (but not MCU ground) and that MCU ground is connected to GPIB pin 24 in addition to all the other ground pins. Jumper wire fixed between PCB ground pad and connector shield in absence of screw.

Board selected in Arduino IDE is Arduino Micro (also tried using Arduino Leonardo). Config.h & firmware has not been modified – all default.  When MCU was fresh out of the packet and connected to the Arduino IDE the default board was Arduino Leonardo.

HP3478a control utility seems to work as it should with the 3478a.  Trying to connect to a 34401a with this utility results in the 34401a going into remote mode – this is the only evidence of communication between controller and 34401a I can get.

[WaveyDipole]

Thank you for the comprehensive screenshot and information.

It looks like the 3478A program is doing some magic to automatically detect the GPIB address of the 3478A and has evidently identified it on GPIB address 6. However, looking at the AR488 Config output on the right hand side, it doesn't look like the interface has been given the GPIB address of the 34401A prior to sending commands to it - unless of course the 34401A happens to be set to address 1? Looking at the 34401A User manual (page 161), the factory setting is address 22, although it can be set anywhere between 1 and 30 so long as it doesn't clash with another instrument.

Probably best to check what GPIB address is configured on your 34401A and then issue a:

++addr nn

to address the instrument, where nn is the GPIB address of the 34401A before sending any commands to it. If the address has previously not been changed then chances are that it is still at factory settings so:

++addr 22
*idn?

should elicit a response from the meter.

[AtlanticSurfer]

Thank you much Wavey, that's what I needed to know.

[WaveyDipole]

Great! Glad that's sorted it. 

[Miti]

Thank you much Wavey, that's what I needed to know.

@AtlanticSurfer  Can I ask what application is this in your attachment?

[Miti]

Even though I have quite a collection of GPIB adapters, you can never have enough, so I've heard, so I couldn't resist and I had to make another one.
A big thank you to WaveyDipole, Artag and Jay_Diddy_B for sending me a PCB.

[AtlanticSurfer]

Miti - I can't remember how or where I came across that perhaps someone else knows but here's a link to it.

It's an executable in an encrypted zip, password is AR488utility.  If you uncheck the "Transfer with Mega" slide switch you should gat a simple download (i hope)

https://mega.nz/file/4ERjzAZK#i7ftiLU8j37xqheS_pOUeO4aOFm38676KiBDONivG3U

[Miti]

It worked, thanks!

Cheers,
Miti