AR488 Arduino-based GPIB adapter

[porter]

I've been testing my adapter on Ubuntu using a modified Perl package. Someone may be thinking about using this package so here are my initial observations.

https://metacpan.org/pod/Device::GPIB::Prologix

Module's initialise method:

Code: [Select]

sub initialised
{
    my ($self) = @_;
 
    return unless $self->version() =~ /^Prologix/;
    # Set the Prologix into a state we like
    $self->auto(0);
    return unless $self->auto() == 0;
 
    return 1; # OK
}
modified as follows

Code: [Select]

sub initialised
{
    my ($self) = @_;
    #
    # needed prior to $self->version() # on AR488
    $self->read();
    #
    return unless $self->version() =~ /AR488/;
    print("initialised:OK\n");
    return 1; # OK
}


Code: [Select]

#!/usr/bin/perl
#
# Send some commands to the HP 5316A
#
use lib '.';
use strict;
use AR488;

$Device::GPIB::Prologix::debug = 1;

my $dev = AR488->new('/dev/ttyACM0:115200:8:none:1:none');
if (!$dev) {
    print ("problem with device\n");
    exit
}
$dev->addr(4);
$dev->auto(1);
$dev->send("IN");
$dev->send("TR0");
$dev->send("FN1");

#
# Initialize to the following
#   FN1 Frequency A
#   AS0 A triggers on positive slope
#   BS0 B triggers on positive slope
#   TR0 A and B trigger based on front panel control
#   WA0 Continuous gating. output if addressed
#   SR0 Polls srq at end of measurement
#   GA0 Gate range is long entered on front panel

my $res = $dev->read();
$dev->close();
print("Reading: $res\n");
output

[AR488]$ ./hp5326A_test.pl
DEBUG: AR488 is connecting to /dev/ttyACM0 with 8:none:1:none
DEBUG: Sending: '++read'
DEBUG: Read: 'AR488 GPIB controller, ver. 0.51.04, 27/01/2022'
initialised:OK
DEBUG: Sending: '++addr 4'
DEBUG: Sending: '++auto 1'
DEBUG: Sending: 'IN'
DEBUG: Sending: 'TR0'
DEBUG: Sending: 'FN1'
DEBUG: Sending: '++read'
DEBUG: Read: 'F     +1.007281E+04'
Reading: F     +1.007281E+04

[8bitcpu]

Tl,dr:
Does anybody here have a lead on SN75161 and SN75160 smd chips with a reasonable lead time?

Hi all,

So I bought NI USB to gpib from amazon for round 100euro, big mistake, turns out it is a fake...
A vey wel done fake, but a fake that doesn't work like it should .
So I got the plan to take it a part en convert it to a AR488.
I want to drive ~5 devices with it so I decided to go with the  SN75161 and SN75160  solution.
And to fit it all in de NI enclosure it all needs to be smd.

Turns out these chips in smd form are unobtainable at the moment.
so my question is:
Does anybody here have a lead on SN75161 and SN75160 smd chips with a reasonable lead time?

Kr

[IanJ]

I buy my GPIB buffers from Ebay. Always seem to work ok.

Ian

[8bitcpu]

@justjason thanks for the offer, but the dip versions are still some what available. but will not fit in my project... if things change I might take your offer.

[leo1984]

hi everyone. i've got a problem...
i can connect to my ar488 (pro micro) with putty on windows and some of the commands were received by the instrument (with ++llo goes in rem mode), but I'm not able to set up the connection in ke5fx... could anyone help me?
the instrument is a par 263a potentiostat.

[dl6lr]

hi everyone. i've got a problem...
i can connect to my ar488 (pro micro) with putty on windows and some of the commands were received by the instrument (with ++llo goes in rem mode), but I'm not able to set up the connection in ke5fx... could anyone help me?
the instrument is a par 263a potentiostat.

Make sure you changed the id: "++id verstr AR488 version 6.102" so ke5fx identifies it as a prologix. See some more findings in the discussion thread I opened, especially those on the read_tmo_ms:
https://github.com/Twilight-Logic/AR488/issues/22

[WaveyDipole]

I have just pushed an update (0.51.09) to the repository that implements a few enhancements and changes:

- improvements and simplifications to configuration, including serial ports and Bluetooth
- changes to serial port and debug handling
- implementation of the ++help command as provided by douardda (with a slight modification)
- minor fixes and corrections
- support for additional boards, including Logic Green LG8FX, MicroCore ATMega644 and ATMega1024
- updates to the relevant sections of manuals (more to follow)

I have also added to the acknowledgements. Apologies if I have missed anyone. There have been lots of helpful messages and ideas both on the thread and in personal messages. These have been very much appreciated. Sadly because of ongoing health problems and other commitments, things are moving along a bit slowly but I am gradually working my way though things.

[justjason]

Would it be possible to set up two AR488 adapters to communicate with each one another ( for the sake of testing ) ?
I have tried to set up one as controller ( mode 1 ) and the other as device (mode 0)  but running a ++spoll from the controller does not seem to find the device. Both are set to address 5.

[macboy]

Would it be possible to set up two AR488 adapters to communicate with each one another ( for the sake of testing ) ?
I have tried to set up one as controller ( mode 1 ) and the other as device (mode 0)  but running a ++spoll from the controller does not seem to find the device. Both are set to address 5.

Every device including the controller needs a unique address. Controller is typically 0.

[justjason]

Every device including the controller needs a unique address. Controller is typically 0.

Thanks for the reply. After discovering a wiring issue, I have it working now.
Using one adapter set as controller, and the other as device in listen only mode, I can pass data between the adapters. In this config, it is not necessary to use different addresses.

[WaveyDipole]

By default, the controller GPIB address is 0.

When the AR488 is set in controller mode using ++addr, this will set the address of the device that the controller will be communicating with across the GPIB bus.

When the address is set using ++addr in device mode, this sets the GPIB address of interface as a device on the GPIB bus.

I had, at one point, considered adding a ++caddr command to allow the GPIB address of the controller to be set to something other than 0, but felt that this was unlikely to be needed. If anyone thinks this will be useful, I can certainly add a feature to allow the user to change the controller address.

justjason, I am glad you have resolved the problem. An AR488 controller and an AR488 in device mode should be able to communicate with each other just the same as it would with any other GPIB device. With the AR488 in device mode you should be able to set a status byte to a value of your choosing and the AR488 should return it to the controller when it conducts a serial poll. The AR488 in device mode should clear the SRQ bit from the status byte once the serial poll has been conducted by the controller. You should also be able to pass data (with caveats) between the two AR488 interfaces.

[Smokey]

Sorry for the basic question...

Is the Artag Pro-Micro firmware a separate project?  It's not clear from the Github repo what is going on there.  Do updates get merged into both?

A better question might be:  What is the Arduino build procedure when using a Pro-Micro?  What code/config needs to be set/used?

[Smokey]

I think I got it.  Having a separate folder in the repo for the original Artag stuff is a little confusing.   I'm not sure why this is still there.  The code is 3 years old.  It at least deserves a comment in the README that says something like:
"This branch is deprecated.  Don't use this.  Here is how you change the config file for a pro-micro......"

I think all I needed to do was uncomment this line in the config file:

Code: [Select]

/*** MEGA 32U4 based boards (Micro, Leonardo) ***/
#elif __AVR_ATmega32U4__
  /*** Board/layout selection ***/
  #define AR488_MEGA32U4_MICRO  // Artag's design for Micro board
  //#define AR488_MEGA32U4_LR3  // Leonardo R3 (same pin layout as Uno)


[WaveyDipole]

That's a fair point and I will remove the older material or move it to the Archive folder.

Yes all you needed to do was un-comment the layout definition in the ATmega32u4 section and comment out the other one. This is covered in the AR488 manual, however I appreciate that having the older code lying around might have been confusing.

[dmikk2]

The Nano Every is not listed as a supported platform, but since it is similar to the Nano I decided to try it.  With a few trivial edits to the code, it does seem to basically work.  Starting with the source code in the latest AR488-master.zip make the following changes.

1. In AR488_Config.h uncomment #define AR488_CUSTOM, to choose a custom layout.  Since this option does not specify a particular cpu/board type, and does not use interrupts, I hoped that this would avoid most hardware specific code.

2. In AR488_Layouts.h copy the Nano pin definitions to the AR488_CUSTOM section.

3. In AR488_Eeprom.h change EESIZE to 256, since the Nano Every only has 256 bytes of eeprom.

4. In AR488_Eeprom.cpp replace the hard coded constant 512 by EESIZE.

5. The file DEVNULL.h is included in AR488_ComPorts.h, but was not on my Ubuntu system or in the Arduino IDE.  Download DEVNULL.h from the web and if necessary, change the include statement to point to the downloaded file.

With these changes, the AR488 project built and could be uploaded to the Nano Every.  To test this, I cut an old GPIB cable in half and soldered the Nano Every onto the exposed wires at the end of the cable.  This has the advantage that the micro USB port can be brought to the front of the instrument.  I'm currently using it to log data from a pair of HP3456a meters, and it seems to be working properly.  Obviously, this is not a thorough test, and there might be problems in other applications.

I appreciate the hard work and expertise that went into the AR488 project.  Thanks!!

[WaveyDipole]

dmikk2,

Thank you for posting these instructions.

Your post raises a couple of interesting points which I shall address in the next update. I will see whether this can be determined automatically, or perhaps add a parameter to AR488_Config.h to allow the size of the EEPROM to be configured manually. Secondly, the DEVNULL library needs to be installed in the Arduino IDE using the Library Manager (Tools->Manage Libraries, search DEVNULL, click Install). I will make sure that the instructions are added to the manual and the repository main page.

[croma641]

Hi, with the last firmware version, Timelab (for my experience) doesn't work anymore with my Hp5334a. In particular, I cannot set the instrument in talk mode.

Has anyone had the same problem?

thanks in advance

[PerArdua]

Hi,

I have tried using the AR488 with driver ICs, based on a design for use with raspberry pis. I ca get the device to commnds to the controllers (such as ++ver, ++id fwver), and have made contact with one instrument (*IDN? successfully with a HP 1650B), however it does work with any other instruments. I have tried using it with a E3632A power supply, which returns nothing and enters an error mode, and similarly on a E4403B spectrum analyzer - with an error for 'query interrupted'.

Would anyone be able to suggest a starting point to identify why these errors occur? I have tried searching, but have found no useful information.

I have also attached my schematic for reference, though I suspect that the hardware is correct, else I would not have seen the IDN response from the 1650B. I have also attached my config file.

[justjason]

A good tool is the

Code: [Select]

x_diag function. Try setting and double checking each pin at the output to make 100% sure of the connections.
https://ar488.readthedocs.io/en/latest/main/xdiag.html

[wilhe_jo]

I've got this code working with the arduino pro micro, which has a built-in USB port. It's also a very small board that fits neatly on the back of a GPIB connector, making a really tiny interface.

I've designed (but not yet received) a PCB to mangle the wiring appropriately but will publish that once it's proven.

Waveydipole has a copy of my changes (which also support the Uno and Mega versions in the same Arduino project) and will make that available in due course.

Apart from the size (an arduino nano also fits quite nicely on the back of a plug), the use of the 32u4 should make it possible to support the RTS/CTS pins correctly (though I haven't tried to do that yet) and maybe at some point support USBTMC as an alternative to serial.

Hi!
After having troubles getting a second Arduino to work (maybe quirky fake cpu?), I opted to spend an afternoon to design something more professional that my current piece of artwork hanging from the back of my trusty 26.5GHz spectrum analyzer.

In the end, I got a vertical usb-c connector, proper ESD diodes and a GD32F350 on a PCB the size of the case of a typical connector.

So the next thing to do is to see which firmware could be ported. The AR488 codebase is a obvious candidate, since I already use this in my custom measurement tools, but USBTMC would be nice as well....

So my question is if there's some fork of the AR488 firmware with USBTMC already?

73

[PerArdua]

Thank you justjason.

I tried using that but have since discovered that all my lines are held high. I tried again, removing my driver board and measuring at the Arduino header pins, but they are all still high and do not respond to commands. i have tried another 328P to be sure the uC wasn't damaged, but again almost all pins are high - even after performing the following tests.

Code: [Select]

++ver
AR488 GPIB controller, ver. 0.51.09, 20/06/2022
++xdiag 0 0
++xdiag 0 255
++xdiag 1 0
++xdiag 0 0
Only pins 3, 6 and 13 on are measured low - the rest are at 5V. I have attached my current config file for reference - the only changes I have made was to enable the driver ICs but uncommenting lines 186, 189 and 190 in AR488_Config.h. note I also had to include DEVNULL.h in the directory as I didn't have that installed. Any ideas as to what might be occuring? I'm using an Arduino Uno board and get these results with and without any other hardware attached.

EDIT: I have also attempted to use a Nano - adjusting only the definitions on line 45/46 in the AR488_Config.h. However I observe the same behaviour - perhaps this a result of my config file being set up in incorrectly - or how I am using ++xdiag? 

[justjason]

GPIB signals an active state by switching to LOW. ie the default state of the pins is HIGH so in the default controller mode,  your pins should be all high at start except REN

++xdiag 0 255 and ++xdiag 1 255  should hold the pins low for ~10 sec.

[PerArdua]

Thanks again JustJason - i admit the 10s caught me out - the AR488 manual doesn't mention it returns automatically haha.

On an Arduino on its own, with no drver ICs selected, using a fresh download of the software, all pins are normally at 5V, and go low as expected when asserted. However, REN is the opposite - it is normally low, but does go high when I send ++xdiag 223. Any ideas what could be causing this, or is REN supposed to be low?

[justjason]

In controller mode ( the default mode) that is normal behaviour. REN low at start

[PerArdua]

Thanks for confirming. I've tried simplifying the hardware by connecting up the connector to the arduino uno directly - no driver ICs. The outputs at the connector measure correct, but when I attempt to communicate with my E3632A (sending a single *IDN?) I get an error 410 - Query Interrupted. From the E3632A manual:

Query INTERRUPTED
A command was received which sends data to the output buffer, but the output buffer contained data
from a previous command (the previous data is not overwritten). The output buffer is cleared when
power has been turned off, or after a *RST (reset) command has been executed.

Any ideas what could be causing this? My process is currently:

1) Connect GPIB connector to instrument.
2) Connect USB between Arduino and PC.
3) Open serial port.
4) send ++ver - this returns the correct response.
5) set address to 6 by ++addr 6
6) send *IDN?
7) Nothing happens - wait for even a few minutes.
send *IDN? again - error 410.

EDIT: Apologies, I realize I wasnt sending a single *IDN? - I would send a single *IDN? as per above, and there would be no response (though the instrument would indicate it is in remote mode due to annunciator REM illuminating on the display). Sending a following *IDN? would trigger the 410 message, which is to be expected if the output buffer still has data. However, I am unsure why it would be hanging.