AR488 Arduino-based GPIB adapter

[mmcgraw74]

WaveyDipole,

I agree with your analysis that a fork of your AR488 code to support a GPIB Device with GPIB commands might be advisable, my software skills are quite rusty and looking at your code - I didn't think I had the skills to do the modifications.

In terms of GPIB bus analysis - I don't think that is necessary, as the Tektronix 4924 Service Manual has very detailed descriptions of the controller to tape drive commands including GPIB cycle by cycle transactions in Appendix B starting on pdf page 192 through page 200:

http://bitsavers.org/pdf/tektronix/405x/4924/070-2131-00_Tektronix_4924_Digital_Cartridge_Tape_Drive_Service_Manual_Feb1982.pdf

The 4924 Tape drive was introduced before the 4050 series computers, so there are several of the commands not used by the 4050 computers.  I captured a list of those commands in my "code" list in post #512 in this thread.

As for the Tektronix-GPIB-Download project, this project provides one device function - screen print graphics from a Tektronix DSO are converted to an SVG graphics file and saved on a SD Flash card.  The DSO (and all the later Tektronix GPIB products) does not use secondary addressing, in fact no commands at all - the Arduino just waits for a GPIB SRQ sent from the DSO when you press the print button on the DSO.

Then I found your project, which supports command parsing (although the commands are from the PC over USB to serial on the Arduino).

I would really appreciate your help as I am not experienced in writing c-code, my coding was in 8-bit assembler and BASIC back in the day.

I'm not familiar with MQTT, but I'm not sure it would apply to this use case.  The Tektronix 4050 computers provided BASIC in ROM which included some of the BASIC commands mapped into GPIB secondary addressing - such as tape reads and writes.  Since I can't change those controller commands, and indeed want to use them as they are already built into the controller and directly support the 4924 tape drive and all the BASIC programs I have captured and posted use those commands - I think it restricts the device to only need to parse and support those commands.

In addition - I don't think Ethernet or WiFi are needed by the tape emulator device, as I just plan to transfer the programs I have recovered directly to the flash drive from my PC - organized into FAT folders for each tape.  The only 'new' command I would want the tape emulator to support is a change directory command - that I would add to the BASIC Menu program that would allow the user to select a particular 'tape' and file.

That "CD" command in my list of supported commands was designed for the Tektronix 4907 8-inch floppy drive system which included hierarchical file storage.  I don't need to support any of the other 4907 commands - and I plan to use the PRINT@5,9: BASIC command to send the "CD" to the tape emulator with the file path as a string variable as the only 'new' command in the set of commands needed for interacting with the tape files.

Since this 'fork' of your AR488 may not be very useful to the other folks, maybe you can start a new thread?

I stand ready to help!

[mmcgraw74]

WaveyDipole,

I have a working Tektronix logic analyzer and GPIB Bus Preprocessor that is untested, but just needs a ribbon cable (I have the right connectors), that I should be able to use to capture GPIB bus transactions. 

I used a 6800 preprocessor module to debug DRAM parity issues with my 4907 Floppy Drive, so I believe I can get the GPIB Preprocessor working too.

[mmcgraw74]

Sorry, I have an HP 16500 logic analyzer and HP GPIB preprocessor module, not Tektronix.

[WaveyDipole]

Sorry, my reference to MQTT (and hance Ethernet and WiFi) was not specific to your project but to the AR488 interface in general.

8in tape drives! That's going back a bit. Saw one at Uni when I was there but it was an obsolete bit of kit in a store room. Not sure what they used it with.

That you for that link. It does indeed contain very detailed information and is something I can work with and on that basis I can start a new project directory and start work on cutting down the code to what is required. I am uncertain as to parsin basic commands. As I understand it these will be issued from the Tek 4050 which will then translate these into GPIB commands and byte sequences to be sent over the GPIB. The tape device will need to read these from the GPIB bus and do something with them emulating the tape drive. What will be required is some means to provide the "tape drive" with a GPIB address so that the Tek 4050 can "talk" to it.

As requested, I have started a new discussion here:
https://www.eevblog.com/forum/projects/tektronix-4924-tape-drive-emulator/msg3168024/#msg3168024

[PixieDust]

I had a think about it and I think I'll just buy some aluminium shielding tape and use that to shield the wires. All I'm trying to do is download the calibration data. I'm not going to use the setup in some demanding RF environment.

I ended up buying some of this aluminium adhesive tape, but after doing some more reading, I'm starting to think it won't work. From what I'm reading if an EMI enclosure has any holes, then EMI can seep out through those. Using the aluminium tape means there's going to be heaps of holes, so shielding will be ineffective. Plus, I realised that you also need to ground the shield and aluminium isn't the best metal for soldering, so the whole thing is starting to look very complicated and probably quite useless. I'll see what cables I have that I don't mind cutting up that have shielding in them. I think that would be a better solution than creating the monstrosity that I had envisaged.

[bitseeker]

BTW, on another topic, I had wondered whether there is any advantage to creating an MQTT enabled version of the AR488? This would use MQTT to configure and control the adapter rather than the Prologix command set and would work over Ethernet and WiFi. Any thoughts?

I'm not sure what specific advantages would be gained from having an MQTT enabled AR488. Might that imply that you could then control your lab's lights and GPIB instruments via Home Assistant?

[WaveyDipole]

That could essentially be the case. The underlying messaging technology behind Home Assistant and HiveMQ is MQTT. I came across this while working with the ESP8266 and ESP32 as well as Ethernet shields and researching the performance problems particularly on WiFi devices. It seems that because HTTPS is quite heavy on resources on an IoT device, MQTT is the recommended as a lighter alternative solution. It then occurred to me that Prologix commands could also be replaced with MQTT messages. There is one drawback in that MQTT does not work over serial so it would only work with TCP/IP connected devices although I don't see why it couldn't via some form of serial gateway, but that's another topic.

[bitseeker]

And there are also the other home automation comm protocols such as Zigbee and Zwave.

[PixieDust]

Found some shielded cables. Job done. But at least I can understand why these cables cost so much. Much more work than I anticipated. Soldering all the shielding to a common ground was especially messy as you can see!

EDIT: D/L the calibration data for my HP3478A, but it looks wierd. Is there some special software that I need to read it? Notepad shows me this:

O@@@BADBECEMML@@@@BACLMLLLH@@@@@BBEDALNEIIIIIDBE@COKE@@@@@@BEMDDNC@@@@@@@@@@@OO@@@@ICCLEDDMG@@@@C@ALNNLLG@@@@@EALAOCMJ@@@@@AALNCLMD@@@@@@ALNNMLI@@@@@@@EEO@NF@@@@@AALMAEMN@@@@@@@EEDAO@@@@AEADNLMOKN@@@@AFDNNMALJ@@@@@@@@@@@OO@@@@ICDOMMOKG@@@@@@@@@@@OO@@@@@@@@

That doesn't look like anything I've ever seen before that would suggest that the data has integrity. From memory, other peoples calibration data looked different/legible.

[Miti]

Looks right to me. Take a look here
https://www.eevblog.com/forum/testgear/free-hp3478a-multimeter-control-program/

And here

https://www.eevblog.com/forum/repair/hp-3478a-how-to-readwrite-cal-sram/

And here
https://www.eevblog.com/forum/projects/project-extending-hp3478a-functionality/

[PixieDust]

https://www.eevblog.com/forum/repair/hp-3478a-how-to-readwrite-cal-sram/

Thanks! Thought I saw calibration data examples somewhere, thanks for the link. I agree, looks like everything worked. I was expecting hexadecimal values.

[eliocor]

I'm using an "artag" interface with a modified ++ver string which contains the string: "Xxxxxxxxx GPIB-USB Controller version 6.101". *
I know the communication is OK: using the 'GPIB Configurator' from "KE5FX GPIB Toolkit" I'm able to read and write to my 34410A.
Unluckily the patched version of EZGPIB is unable to identify the AR488 interface: the debugging window reports the following text (COM30 is the AR488 interface):

 see attachment, please.....

    any suggestion?
 
 
*) replace Xxxxxxxx with the correct name!

[maxwell3e10]

I found that for me it works on the second time, just start EZGPIB again.

[eliocor]

tested patched EZGPIB (2012-12-17) on two other computers (W10) with unluckily the same results.... 

[pqass]

EDIT: D/L the calibration data for my HP3478A, but it looks wierd. Is there some special software that I need to read it? Notepad shows me this:

O@@@BADBECEMML@@@@BACLMLLLH@@@@@BBEDALNEIIIIIDBE@COKE@@@@@@BEMDDNC@@@@@@@@@@@OO@@@@ICCLEDDMG@@@@C@ALNNLLG@@@@@EALAOCMJ@@@@@AALNCLMD@@@@@@ALNNMLI@@@@@@@EEO@NF@@@@@AALMAEMN@@@@@@@EEDAO@@@@AEADNLMOKN@@@@AFDNNMALJ@@@@@@@@@@@OO@@@@ICDOMMOKG@@@@@@@@@@@OO@@@@@@@@

That doesn't look like anything I've ever seen before that would suggest that the data has integrity. From memory, other peoples calibration data looked different/legible.

The calibration data looks as expected.

Basically, the first byte is thrown-away and the rest is divided into 13 byte records.
To understand how to interpret and verify each record, I refer you to my previous post: https://www.eevblog.com/forum/testgear/first-bench-multimeter-fluke-8840a-vs-hp-3478a/msg3008694/#msg3008694.

But since that post, I have created the following [linux] shell script (verify.sh) to dump and verify the raw calibration data.

Code: [Select]

#!/bin/sh

if [ -f "$1" ]; then
cat "$1" | od -A x -t x1z -w13 --skip=1 | awk 'BEGIN{
SEP="|";
rectypestr="30 mV DC" SEP "300 mV DC" SEP "3 V DC" SEP "30 V DC" SEP "300 V DC" SEP "<not used>" SEP "AC V" SEP "30 Ohm 2W/4W" SEP "300 Ohm 2W/4W" SEP "3 kOhm 2W/4W" SEP "30 kOhm 2W/4W" SEP "300 kOhm 2W/4W" SEP "3 MOhm 2W/4W" SEP "30 MOhm 2W/4W" SEP "300 mA DC" SEP "3A DC" SEP "<not used>" SEP "300 mA/3A AC" SEP "<not used>" SEP "<padding>";
rectype[0] = "";
split(rectypestr, rectype, SEP);
}{
crc=0;
if(NF==15) {
for(i=1; i<NF; i++)
if(length($i)==2)
crc += strtonum("0x"(substr($i,2))""((i==13)?"0":""));
printf "%s\t// %.2d\tcrc=%x\t%s\n", $0, (NR-1), crc, rectype[NR];
} else if(NF>1) {
printf "%s\t// %.2d\t\t%s\n", $0, (NR-1), rectype[NR];
}
}'
else
echo "$0 <cal file>"
fi

Running it with your raw calibration data produces the following:

Code: [Select]

$ ./verify.sh PixieDust.cal
000001 40 40 40 42 41 44 42 45 43 45 4d 4d 4c  >@@@BADBECEMML< // 00 crc=ff 30 mV DC
00000e 40 40 40 40 42 41 43 4c 4d 4c 4c 4c 48  >@@@@BACLMLLLH< // 01 crc=ff 300 mV DC
00001b 40 40 40 40 40 42 42 45 44 41 4c 4e 45  >@@@@@BBEDALNE< // 02 crc=ff 3 V DC
000028 49 49 49 49 49 44 42 45 40 43 4f 4b 45  >IIIIIDBE@COKE< // 03 crc=ff 30 V DC
000035 40 40 40 40 40 40 42 45 4d 44 44 4e 43  >@@@@@@BEMDDNC< // 04 crc=ff 300 V DC
000042 40 40 40 40 40 40 40 40 40 40 40 4f 4f  >@@@@@@@@@@@OO< // 05 crc=ff <not used>
00004f 40 40 40 40 49 43 43 4c 45 44 44 4d 47  >@@@@ICCLEDDMG< // 06 crc=ff AC V
00005c 40 40 40 40 43 40 41 4c 4e 4e 4c 4c 47  >@@@@C@ALNNLLG< // 07 crc=ff 30 Ohm 2W/4W
000069 40 40 40 40 40 45 41 4c 41 4f 43 4d 4a  >@@@@@EALAOCMJ< // 08 crc=ff 300 Ohm 2W/4W
000076 40 40 40 40 40 41 41 4c 4e 43 4c 4d 44  >@@@@@AALNCLMD< // 09 crc=ff 3 kOhm 2W/4W
000083 40 40 40 40 40 40 41 4c 4e 4e 4d 4c 49  >@@@@@@ALNNMLI< // 10 crc=ff 30 kOhm 2W/4W
000090 40 40 40 40 40 40 40 45 45 4f 40 4e 46  >@@@@@@@EEO@NF< // 11 crc=ff 300 kOhm 2W/4W
00009d 40 40 40 40 40 41 41 4c 4d 41 45 4d 4e  >@@@@@AALMAEMN< // 12 crc=ff 3 MOhm 2W/4W
0000aa 40 40 40 40 40 40 40 45 45 44 41 4f 40  >@@@@@@@EEDAO@< // 13 crc=ff 30 MOhm 2W/4W
0000b7 40 40 40 41 45 41 44 4e 4c 4d 4f 4b 4e  >@@@AEADNLMOKN< // 14 crc=ff 300 mA DC
0000c4 40 40 40 40 41 46 44 4e 4e 4d 41 4c 4a  >@@@@AFDNNMALJ< // 15 crc=ff 3A DC
0000d1 40 40 40 40 40 40 40 40 40 40 40 4f 4f  >@@@@@@@@@@@OO< // 16 crc=ff <not used>
0000de 40 40 40 40 49 43 44 4f 4d 4d 4f 4b 47  >@@@@ICDOMMOKG< // 17 crc=ff 300 mA/3A AC
0000eb 40 40 40 40 40 40 40 40 40 40 40 4f 4f  >@@@@@@@@@@@OO< // 18 crc=ff <not used>
0000f8 40 40 40 40 40 40 40 40 0a              >@@@@@@@@.< // 19 <padding>

"crc=ff" means that the record passed verification; any other value means that it failed.
"@@@@@@@@@@@OO" means that the record is unused and the last incomplete record is just padding.

All your records are correctly verified. Yay!

EDIT: For completeness, I've updated the script and output to include a note about which meter range the record pertains to.

[WaveyDipole]

I'm using an "artag" interface with a modified ++ver string which contains the string: "Xxxxxxxxx GPIB-USB Controller version 6.101". *
I know the communication is OK: using the 'GPIB Configurator' from "KE5FX GPIB Toolkit" I'm able to read and write to my 34410A.
Unluckily the patched version of EZGPIB is unable to identify the AR488 interface: the debugging window reports the following text (COM30 is the AR488 interface):

 see attachment, please.....

    any suggestion?
 
 
*) replace Xxxxxxxx with the correct name!

That is curious. On boards that use a hardware UART, connecting to a serial port causes a reset and EZGPIB does not allow enough time for this before reading the serial port, with the result that it reads a blank line. One way around this is to put a 10uF capacitor between RESET and GND which prevents a reset (and prevents programming). However, this shouldn't be an issue with Micro Pro/Leonardo 32u4 type boards which use software emulated CDC ports and do not reset. As maxwell3e10 reports - and I have observed this behaviour myself - often it will succeed on a second attempt, almost as if the serial connection is being held open or something between attempts. I do have a 32u4 Micro Pro board here so will dig it out and run a test. Are you using USB or TXO/RXI pins for serial comms?

[eliocor]

I'm using an "artag" interface (v3 PCB) with a Micro Pro with installed the latest 0.48.28 fw version. 
I'm using the USB connection: outside EZGPIB the interface is working flawlessly.

[WaveyDipole]

I just tried the "Artag" interface with the original copy of EZGPIB on Windows 7 and got the same result. EZGPIB fails to recognize the interface. I tried the patched version but found that it sits minimized in the task bar and even if you click on the icon in the task bar, the programming window never opens. Just to be sure, I deleted my patched copy of EZGPIB and re-created a new copy from scratch but got the same result. I did find that if I change the line in EZGPIB.ini:

SearchSERIAL=True

to:

SearchSERIAL=False

then it will start normally. Of course, in this case it no longer scans serial ports in an attempt to detect the interface and there is no means to specify one manually. The patch process is somehow causing the program to hang.

I had no problem starting the patched version of EZGPIB on Windows 10 although there was a small delay before the program window opened. However, as per your report, the interface was not recognized. At this point I am uncertain as to what the problem is, but I suspect it is about timing. I will investigate further when I have the time.

[artag]

I was under the impression that EZGPIB refuses most versions of the AR488 interface. I believe it looks for active RTS/CTS flowcontrol lines. These exist on the FTDI chip (and, therefore very old arduinos such as Duodecimilia) but not on most modern arduinos. The CH340 has them - though they're not normally connected - but I'm not sure if EZGPIB knows that driver either.

The 32U4-based AR488 uses the standard arduino usb-device driver which implements a CDC serial interface. It has RTS and DTR, I think.

I originally hoped to modify the driver to handle RTS as well but that doesn't just require a driver mod, it requires a new driver that emulates an FTDI or possibly CH340 interface and therefore has a Windows driver that handles that .. but since I don't really use Windows it's not very far up my list of jobs .

The alternative is to patch EZGPIB so that it doesn't look for the handshake lines. This is probably the easiest course of action.

[jimmc]

For Arduinos using the CH340G (e.g. NANO clones), grounding pins 9 & 10 Of the CH340G will assert CTS & DSR.
I can confirm that they will then be recognised by EZGPIB.
(see https://www.eevblog.com/forum/testgear/gpib-interface-(ieee488)/msg1148751/#msg1148751)
Jim

[maxwell3e10]

I got this patched copy of EZGPIB from someone that seems to work OK in Win 7 on second try.

[ElektroQuark]

This AR488 works with multiple targets or only with one?

[eliocor]

@maxwell3e10:
your .exe file is the same as the "standard" patched one....
Maybe I should resort to use IDA/Ghidra to try to find if it can be corrected.

[artag]

This AR488 works with multiple targets or only with one?

There are commands to select the GPIB address of the device being used (for multiple targets), but you can also set it for a single address, when it will act as though it were serial over USB to a single device.

[xardomain]

Which is the string shown in the debug log about  the ++ver string?
I am using a Leonardo clone, and with the patched version apparently the ++ver does not return anything.

I was successful in reading the frequency from a Racal Dana 1998 frequency counter and changing the gate time by hand, using putty.

I plan to use it with Lazarus IDE, so can't say how much I will lose using EZGPIB. I have another GPIB adapter(PCI), EZGPIB works with this no problem.

Timing issue?

Giuseppe Marullo
IW2JWW - JN45RQ