AR488 Arduino-based GPIB adapter

[WaveyDipole]

It was created by and mentioned earlier in the thread by Nx-1997:

https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg3431088/#msg3431088

He also has another tool called LiveGraph. See a couple of posts below the one in the link.

[dl6lr]

I have created a 3d printed enclosure for the adapter with a pro micro.
See https://www.thingiverse.com/thing:4776409for details and all files.

Edit: Fixed URL after re-publish to Thingiverse

[Jay_Diddy_B]

Hi,

I am struggling with a VB .net application.

I have built an AR488 using a Pro Micro 32U4 on Artag's PCB. It works fine with most applications.

I am having trouble with System.IO.Ports in Visual Studio. It seems to want the serial port operating at a standard baud rate. It seems to have difficulty with the virtual serial port on the Pro Micro.

I tried the AR488 software on a Arduino Uno and I can transmit and receive the ++ver command and the response. This works if I set the baud rate to 115200.

Anybody seen this?

Any solutions?

Thanks!!

Jay_Diddy_B

[artag]

I have created a 3d printed enclosure for the adapter with a pro micro.
See https://www.thingiverse.com/thing:4774570 for details and all files.

Nice ! I like the way is screws together.

Could you make a version with less height ? I have usually built them with no socket for the 32u4 board, so there's only 3mm between boards or 13mm from the 24 pin socket flange to the top of the USB socket housing.

[dl6lr]

I have created a 3d printed enclosure for the adapter with a pro micro.
See https://www.thingiverse.com/thing:4774570 for details and all files.

Nice ! I like the way is screws together.

Could you make a version with less height ? I have usually built them with no socket for the 32u4 board, so there's only 3mm between boards or 13mm from the 24 pin socket flange to the top of the USB socket housing.

If you look closely on Thingiverse, there is already such a version (which is only slightly less in height as the screw is then above the board). I haven't tested it yet, but I will.
Unfortunately a version with the UNC(?) screws toi secure it to a device are only possible with the higher version and you have no possibility to use it without a screw driver, as it must be countersunk so tht the USB-Micro-plug can be attached afterwards. Still unsure if I should make such a version (I have no such screws available here).

Unfortunately Thingiverse has some problems and the original upload got corrupt, so I reuploaded it to https://www.thingiverse.com/thing:4776409

Artag, if you want some for tests, I can send them to you if you don't have access to a makerspace with a printer.

[AtlanticSurfer]

dl6lr, the enclosure transfers all the mechanical forces to the metal shell without the connector pins being stressed and it protects the USB port.  It doesn’t require many additional parts – looks like just a fastener and a couple of 12 pin headers.  It protects all the contacts from being shorted  - and looks neat and there's no messing around with glue - good job!

Edit: forgot to mention about the MCU being removable - bonus!

[WaveyDipole]

I am having trouble with System.IO.Ports in Visual Studio. It seems to want the serial port operating at a standard baud rate. It seems to have difficulty with the virtual serial port on the Pro Micro.

I tried the AR488 software on a Arduino Uno and I can transmit and receive the ++ver command and the response. This works if I set the baud rate to 115200.

An interesting observation but 115200 is a standard baud rate. If Visual Studio cannot handle that speed, you could always try 57600 or 38400. Also set #define AR_SERIAL_BAUD to the same in AR488_Config.h.

[dl6lr]

I am having trouble with System.IO.Ports in Visual Studio. It seems to want the serial port operating at a standard baud rate. It seems to have difficulty with the virtual serial port on the Pro Micro.

I tried the AR488 software on a Arduino Uno and I can transmit and receive the ++ver command and the response. This works if I set the baud rate to 115200.

An interesting observation but 115200 is a standard baud rate. If Visual Studio cannot handle that speed, you could always try 57600 or 38400. Also set #define AR_SERIAL_BAUD to the same in AR488_Config.h.

If I remember correctly, the System.IO.Ports.SerialPort opens and operates the port in default configuration of the OS, unless told otherwise. Normally the Windows ports are set to something like 9600,8,N,1. So you have to set the properties of BaudRate etc. before opening the port, or you could just change the default port configuration of the OS in the device manager.

[Jay_Diddy_B]

Hi,

I don't know the problem is. Here is a picture of my two adapters:




The one on the right is the Artag PCB with a Pro Micro attached. The one on the left has a Arduino Nano attached by a bunch of wires. The one on the left which uses the CH340C interface chip works fine with Visual Studio at 115200 baud. The Pro Micro doesn't work with Visual Studio at any baud rate. It will work with other programs.

Jay_Diddy_B

[Nx-1997]

Here is a simple script for C#, I can connect to the pro micro version without any issues. Make sure that the request to send property is enabled.

[Jay_Diddy_B]

Here is a simple script for C#, I can connect to the pro micro version without any issues. Make sure that the request to send property is enabled.

Hi group,

Nx-1997 nailed the issue. It was the RTS line parameter. I had a mental blockage. I thought that if I set the handshaking to none, the RTS line would not be used.

Here are some parts of the code:





And the main part:




This includes a quick and dirty delay to allow the AR488 to respond and fill the serial port input buffer.

The result:




The program sends ++ver and displays the response in a textbox.

Thanks again!!

Jay_Diddy_B

[l3VGV]

Just in case, here is a nice python ar488 example
https://github.com/gkeeth/python-AR488-USB-GPIB/blob/master/ar488.py

[mcj7247]

First a big thank you to WavyDipole who was a huge help. I was able to connect the AR488 and an Arduino Pro Mini w/FTDI to my HP3478A and was also able to connect to the HP3478A Control Software App to download my calibration constants and a cal file. It wasn't without a little drama along the way however. In the middle of my GPIB adapter setup my meter front panel buttons decided to stop working properly. After a few deep breaths and a few emails to WavyDipole we confirmed that the meter was still alive and I was able to troubleshoot and fix a bad connection between the main pcb and the front panel button matrix pcb. All front panel buttons started working fine again....just an evil coincidence and disaster averted. I edited the 488 config file to use the custom layout for the Pro Mini that was previously mentioned by another poster (wkr?). I was able to connect to my meter and all the AR488 commands worked fine. My real need was to have a calibration backup plan for replacing my memory battery and the old capacitors. Initially I tried to use the newest version (04-18-20) of the HP3478A control software but it would lockup when ever I tried to edit or read the cal data. Eventually I tried an older version HP3478AGainCheck (01-18-20) and was able to download a cal file that WavyDipole confirmed was valid. I also was able to view and write down the constants from the edit cal window. I haven't tried to write the cal data back to the meter and still have yet to replace the battery and caps. But a big thank you again to WavyDipole for helping me out and for developing and sharing such a helpful tool.

[AtlanticSurfer]

Here’s how my builds look in the end..

[geshka]

Team.

I am having troubles communicating with this adapter to my Agilent E3631a power supply.  I've  made GPIB-USB on Arduino UNO with all connections as per manual.  I can communicate with Arduino itself and set parameters with ++ commands, I've set address of the device to the controller, hovewer attempt to talk to device is unsuccessfull.  I verified all connections and it seems to be fine.... 

What would be  troubleshooting steps?   any suggestions ? Thanks.

[eliocor]

@geshka: if you can communicate with the arduino (++ commands),
you have to double check your wiring between the arduino and the Cannon (IEEE 488) connector.
The culprit is there!

[WaveyDipole]

Just to be sure, go over and verify the wiring including ground connections. Make sure that the GPIB interface is selected on the instrument. Apparently you can enable only one at a time, either RS232 or GPIB. Make sure its not set to RS232.

If that does not resolve it, then do you have a logic analyser?
You can probably check the state of individual lines (e.g. ATN should go low when a command is issued) with a DMM, but an LA would make things much easier.

[geshka]

Still no luck.  Verified connector for several times, made sure it is indeed GPIB port and right address... I don't have logic analyzer unfortunately, but can watch individual signals with the scope.  I just checked  ATN -  it gos low with every command issued

[serg-el]

Don't forget - the pin numbering is different for the GPIB and for the connector!

[geshka]

I am checking pinout and connection diagram from github pdf and verifing with original post from Emanuele blog....  Something fundamentally stupid   

[wkb]

mirrored?

[WaveyDipole]

You could try turning on ++verbose. The messages might give a clue.
I don't suppose you have another instrument with a GPIB connector to try?

[geshka]

Here is output with ++verbose turned on and precompiled several debugs

> *idn?

Set GPIB lines for sending a command
gpibWriteByte: timeout waiting for data to be accepted - [NRFD asserted]
gpibSendCmd: failed to send command 3F to device
gpibSendData: failed to address device 5 to listen


> ++read


Set GPIB lines for sending a command
gpibWriteByte: timeout waiting for data to be accepted - [NRFD asserted]
gpibSendCmd: failed to send command 3F to device
Failed to address the device5 to talk
Set GPIB lines for reading data
gpibReceiveData: Start listen ->
Before loop flags:
TRNb: 0
rEOI: 0
ATN:  0
gpibReadByte: timeout waiting DAV to go HIGH
0
After loop flags:
ATN: 0
TMO:  2
Bytes read: 1
Timeout waiting for transfer to complete!
Set GPIB lines for sending a command
gpibWriteByte: timeout waiting for data to be accepted - [NRFD asserted]
gpibSendCmd: failed to send command 3F to device
gpibSendData: Failed to untalk busSet GPIB lines to idle state
<- End listen.

 

[WaveyDipole]

Thank you for your output with verbose and debugs turned on. It seems the device is failing to respond to the very first byte of data being sent to it. We haven't even got as far as addressing the instrument.

You did confirm earlier that ATN was being pulled low. From the output we see a timeout has occurred when sending the NRFD signal during the handshake while sending the first byte. From the preceding steps in the handshake process we can surmise that NDAC was low, indicating the device was at attention and NRFD was high, indicating that the device was ready to receive data. The AR488 interface then placed the first byte (3F) on the bus and asserted DAV (data available). However, the instrument does not respond by asserting NRFD to indicate that it has accepted the data.

Since you said that you checked the wiring several times, one would have to presume that it wasn't mirrored as wkd suggested, i.e looked at from the opposite perspective, and that all wiring, including ground was correct. In which case, the instrument is either not detecting the DAV signal, or else not replying to it to say has read the first byte (3F) from the GPIB bus. This might suggest that the GPIB interface on the instrument may be faulty or simply not ready to receive data for some reason. Trying the AR488 on another instrument would confirm or rule out the GPIB hardware on the instrument side of things.

You can also try the ++xdiag command as described at the very end of the manual, without the interface being connected to the instrument. This allows the status of each signal to be set and flipped to confirm that the GPIO pin is working correctly. Bear in mind that the effect of the command lasts about 10 seconds before the line state reverts to the interface default. Its a bit tedious to do with a DMM, but it would prove whether all the GPIO pins on the Uno are working as expected.

[maxwell3e10]

Looks very cool! I'd love to use a similar program for HP3457A. Since it requires extra commands to read 7th digit, one is often forced to use a program instead of simply getting readings from the meter.