AR488 Arduino-based GPIB adapter

[coromonadalix]

I dont think it would be a problem if you redefine/redirect the pins in the file ?

[artag]

It can be defined in the file, yes, but it also needs some conditional compilation to use the correct mask register (the current sources use PCMSK2 which doesn't exist on the 32u4).  It probably also affects the bit-shifting and masking used to shuffle the control and maybe data bits.

Technically that's fine, but if the same registers are used in both versions the code is tidier.

[WaveyDipole]

There maybe some timing parameters that need to be fine-tuned. For me it worked just fine with HP 3457A, but when I hooked it up to HP53310A, it would sometimes have problems, reading only the first character of the instrument's response string. If I upload the original Girlando's sketch to the same board, it works fine.

I spent quite a bit of time looking at the timing today. Since I do not have the instruments that the problem was observed with and cannot replicate the problem here, I could only compare the behaviour of Emanuelle's code and mine. My investigation did reveal what seems a minor difference in behaviour of the interface when transitioning between addressing the instrument and reading data. I have tinkered a little with the code to try and address this issue, but it seemed to have little or no impact when reading my Solatron meter so the investigation was otherwise inconclusive.

I did notice that the UNO reads my Solatron meter OK, but the NANO does have a problem with misreading the first character. Having looked at traces on the logic analyser, the reason could be tracked down to a spurious blip on D3 (A2) which occurs just a fraction after the start of the handshake to read a character. Consequently the value of the byte on the bus is being mis-read as 0x2F instead of 0x2B resulting in '+' being transformed into '/'. The effect is reproducible and consistent and occurs regardless of whether I use the GPIB6.1 or the AR488 code. It does not occur on the UNO board works perfectly fine every time. It would therefore seem to be a problem with the NANO. Once key difference is that the UNO has a proper shielded cable to the instrument, whereas the NANO sits on a prototype board and is hooked up to the UNO via Dupont wires, so it could be that the jumper wires are picking up interferance from something.

I have now uploaded an modified sketch (AR488.ino.0.46.12a) to the GitHub, but I consider this an experimental version rather than a release, which is why I have placed it accordingly in a directory called 'Experimental'. As per suggestions earlier on the thread, I have also added 3 commands for configurable timing parameters:

++tmc - settling time after changing GPIB control state
++tmd - settling time after placing a data byte on the GPIB data bus
++tml - read loop delay (delay between reading characters)

Each parameter can be set between 0 and 255 microseconds.

The default settings are tmc =3, tmd = 3, tml = 0; Please note that if a configuration has been previously saved in EEPROM, then the values of 255,255,255 (i.e. 0xFF) will be read back from the empty EEPROM space, so these parameters will need to be set with the appropriate command and the configuration saved with ++++savecfg command. Alternatively, use +default, then set up the interface as required and save the config with ++savecfg.

I would like to request further observations about the following:

1. Is there a correlation with the board being used, i.e. does the problem happen only on the NANO or on both NANO and UNO?

2. Does changing the newly added timing parameters have any effect?

3. Is there anyone with a meter that exhibits this problem that also has a Logic Analyser and could provide me with a trace, particularly of the ATN, NDAC, NRFD and DAV signal lines along with the data lines (A01 thru A04 would probably suffice for reference but all 8 bits would be ideal) while doing a ++read command for reference?

Incidentally, an issue was logged on the GitHub by 'cabo' to point out that I had omitted the ground connections in the cross-reference table in the manual. My apologies for this and hopefully no one would have omitted a ground connection from their interface assembly, but a ground connection is essential and the details have now been added to the manual.

Any information that can help nail this problem will be much appreciated.

Would it be a big problem to move the SRQ and ATN pins to port B ? That's Uno / Nano pins in the range 8-13.

Since Pins 8-12 are already occupied, there is only one pin, pin 13, left remaining on port B. On the UNO, that pin is connected via a resistor to an 'internal' on-board LED. This electrical difference was the reason why I was advised to avoid using pin 13 as a standard IO pin. I don't think that the NANO has this arrangement but the LED could be removed from the UNO if desired. There is also pin 6 available on port D. It would have been nice if the 8 control signals could be placed on one port and the 8 data signals on another, but alas this is not possible with the layout of the 328p.

Looking at the datasheet for the 32u4 it looks like at bit of work would be required to re-shuffle things and although I am not averse to this, there are other differences such as the position of the Tx and Rx pins which would make obtaining a consistent layout between the 328p and the 32u4 difficult. I will need to have a think about how to approach this.

[maxwell3e10]

I have found that setting ++tmd parameter to 120 or larger makes the errors for HP53310A fairly infrequent, although they still happen once every few hundred commands or so even if ++tmd is set to 255. The other parameters don't seem to have any effect.

[vindoline]

WaveyDipole, this re-write is great! I've been using the Girlando code for a couple of years now with a couple of minor modifications. There is some issue with my HP 3456A. It would randomly reset the adapter. My Keithley 196 worked perfectly. With your code I've had NO PROBLEMS with the HP! It just WORKS! THANK YOU!

[vindoline]

Another thing, I laid out a small 50x50 board for the GPIB adapter. Unfortunately, I wired the SRC line to a different Arduino pin than WaveyD did. I want to make a few changes to the layout now that I've been using it for a few years, so I'll change the pinout also. Anyhow, I have a few boards left. If anyone wants one, message me.

All the adapter boards I've seen (including mine) stick out horizontally behind the GPIB connector. That makes the boat-anchors stick out even farther from the wall and it's rather fragile. My next board will sit vertically. I'll post the new gerbers and layout files when I finish. Thanks again.

[Krampmeier]

Oops, I should have noticed that there were no grounds connected, but I sheepishly followed the wiring list and did not connect those pins at all.
I bodged in at least one temporary GND connection now, and that seems to have fixed the "first character wrong" problem.

With the Keithley 2000, the read stops consistently after the first character is received now. When I send the ++read command again,  I get the complete answer (so the first character is now on the screen twice) and the DMM beeps and shows Error -410 (Query interrupted).

Setting the ++tmd to 250 made that problem appear less frequently, about once in 20 ++read commands.
Lower tmd settings (like 100) did not help.

Changing both occurences of delayMicroseconds(AR488.tmd); to delayMicroseconds(10*AR488.tmd); and setting tmd to 50 seemed to fix the problem completely.

[WaveyDipole]

I have found that setting ++tmd parameter to 120 or larger makes the errors for HP53310A fairly infrequent, although they still happen once every few hundred commands or so even if ++tmd is set to 255. The other parameters don't seem to have any effect.

I bodged in at least one temporary GND connection now, and that seems to have fixed the "first character wrong" problem.

With the Keithley 2000, the read stops consistently after the first character is received now. When I send the ++read command again,  I get the complete answer (so the first character is now on the screen twice) and the DMM beeps and shows Error -410 (Query interrupted).

Setting the ++tmd to 250 made that problem appear less frequently, about once in 20 ++read commands.
Lower tmd settings (like 100) did not help.

Thank you for those ovservations, which have proved very helpful.

It has now become evident to me that after a few hours spent reviewing logic analyser traces and experimenting, that tiredness took its toll and an error had crept in to the experimental code. The instance of AR488.tmd in line 2555 actually affects the writing of data on the GPIB bus rather than reading from it. It therefore seems unlikely that this instance of the variable actually had any impact, except maybe affecting the length of time that it would have taken for the controller to send commands to the instrument. However, no one actually reported an issue with that.

The second instance in line line 2731, is most likely the one that made the difference. However, the variable here should have been AR488.tmc. My apologies for the typo.

This particular delay occurs each time the status of the control bus changes between different controller states. I don't quite understand why a delay here should be necessary at all, but I have made some further adjustments to the code. The second instance of the AR488.tmd variable has now been changed to AR488.tmc as it was originally meant to be. I have also removed the instance of AR488.tmd from the data writing routine and placed the "tmd" delay to occur between the controller addressing the instrument and the instrument sending data. The delay starts at the point that ATN is un-asserted and the controller switches into listening mode. The controller will pause keeping NRFD asserted, indicating that it is not yet ready to accept data. The instrument will have to wait until the delay ends, at which point NRFD will be un-asserted to indicate that the controller is now ready to accept data and receiving of data from the instrument will commence.

Changing both occurences of delayMicroseconds(AR488.tmd); to delayMicroseconds(10*AR488.tmd); and setting tmd to 50 seemed to fix the problem completely.

Well its interesting to note that the time interval needed to be increased well into the millisecond range. Quite why some instruments run Ok with no delays at all and start to play up only when they are present and exceed certain thresholds, while others actually require delays of several milliseconds I am not sure. I did note that Emanuelle's code has programmed delays of 20-30ms in between sending commands and after changing the status of ATN. I initially figured on not introducing any unnecessary delays, but it seems that sometimes they are essential.

The tmc and tmd parameters can now be with values up to 30,000 microseconds (30 milliseconds). I expected that the interval between each character (tml) would turn out to be significant, but since it has been reported that this parameter had no effect, I guess it isn't.

I have uploaded an updated sketch AR488.ino.0.46.12c into the Experimental directory.

I will be interested to know whether whether the value of tmc or tmd now solves the problem.

I am also curious as to whether the instruments with the problems support IEEE 488.2 and/or HS488? I did have a look at a couple of Keithley manuals (the 2000 and the 2015) and I think both are IEEE 488.2 compliant, but it is not entirely clear whether they support HS488. I am speculating whether some instruments are trying to use HS488 mode? Perhaps the delays are necessary in order for them to recognize a standard mode device and fall back to the standard GPIB protocol.

[Krampmeier]

I did not have much time to test it, and it will take a couple of days before I have, but a quick check with the Keithley 2010 showed that the situation got even stranger.

TMD = TMC = 500 and TML = 100 -> First character "-" is often read as "m", the entire string is read only every second time, and the meter shows error -410
Increased TMD to 1000 -> no change
Also Increased TMC to 1000 -> some readings work fine, but 1 out of 10 times still get the error.
TML to 3 -> same
TMD to 3 -> OK.
TMC to 500 -> Error is back consistently.

So, it works with TMD=TML = 3 and TMC = 1000.

WaveyDipole, I have sent you a personal message which may help to speed up the bugfixing process.

[artag]

All the adapter boards I've seen (including mine) stick out horizontally behind the GPIB connector. That makes the boat-anchors stick out even farther from the wall and it's rather fragile. My next board will sit vertically. I'll post the new gerbers and layout files when I finish. Thanks again.

I've got a layout that puts a Nano directly behind a straight male connector, so the resulting board is the same size as the connector itself, as deep as two stacked pcbs (one for the connnector, one is the nano) and the usb cable comes out the end. Could be a problem if you use jack screws, but it's quite compact.

I'm not going to get any made until I'm happy with the connections and I'll probably actually go for the pro micro layout instead. But you're welcome to work on it if you want  (it's in Kicad format).

The Nano can be a bit better than the Uno as it has all of port C available (it adds A6 and A7). So maybe it's not worth trying to keep them all the same but instead make a way to keep the code differences supported tidily - the existing structure is good except for the interrupt inputs which have the port hardcoded in the form of the mask register.

Thanks very much to waveydipole for pushing this forward. I know IEEE-488 is a bit unloved these days but this sort of hack could drag a lot of fine instruments into modern setups cheaply and easily. I much prefer putting a $5 adapter on every instrument than having a single interface and a lot of thick cabling. There are a lot of possible alternate implementations once we have good stable code - arduino, blue pill, cypress ez-usb (the cheap 'saleae clone' boards) & others.

[artag]

I'm seeing similar results to Krampmeier using a K2015 and 0.46.12c, except that tml=tmd=3 and tmc=1000 gives similar works / fails alternately (with the sign only transferred sometimes).

Oddly, it worked fine on *idn? initially, even with the 0.46.10 code, then started failing for no apparent reason.

I should be able to get logic analyser traces (might take me a day or two) and also have hp instruments, but not sure I can get a 'good' trace. What signals do you want to see ? I do have wide analysers but the 8 bits of a Saleae is by far the easiest to acquire.

[coromonadalix]

All the adapter boards I've seen (including mine) stick out horizontally behind the GPIB connector. That makes the boat-anchors stick out even farther from the wall and it's rather fragile. My next board will sit vertically. I'll post the new gerbers and layout files when I finish. Thanks again.

Thanks very much to waveydipole for pushing this forward. I know IEEE-488 is a bit unloved these days but this sort of hack could drag a lot of fine instruments into modern setups cheaply and easily. I much prefer putting a $5 adapter on every instrument than having a single interface and a lot of thick cabling. There are a lot of possible alternate implementations once we have good stable code - arduino, blue pill, cypress ez-usb (the cheap 'saleae clone' boards) & others.

I would not say unloved,  the problem is  :  too much fakes from china,  genuines if you find any, are very high priced  and you're not totally sure they are still legit ..

This project is a big helper, you learn while you build it    I think the only thing left is timing issues ??    the IEEE-488 is not perfect across many brands  i think.

Great work and thanks to thoses working and finding the glitches

[WaveyDipole]

The Nano can be a bit better than the Uno as it has all of port C available (it adds A6 and A7). So maybe it's not worth trying to keep them all the same but instead make a way to keep the code differences supported tidily - the existing structure is good except for the interrupt inputs which have the port hardcoded in the form of the mask register.

While it is true that it does have the whole of port C available, pins A6 and A7 on the NANO are ADC inputs only. There is no digital or output capability  and there is no input pull-up resistor. It would not be possible to use them to send data to the GPIB bus. It would have been helpful if this were possible and would have made coding easier.

I should be able to get logic analyser traces (might take me a day or two) and also have hp instruments, but not sure I can get a 'good' trace. What signals do you want to see ? I do have wide analysers but the 8 bits of a Saleae is by far the easiest to acquire.

If you have an 8 bit Saleae, then ATN, NRFD, NDAC, DAV and the first 4 data bits would be helpful. A couple of captures of the ++read command should suffice. If one of them does a partial read, then both the partial read and the following read would be useful. I am considering porting the code to the Mega2560. I haven't really looked into Blue Pill or other microcontrollers yet.

[artag]

I'd forgotten the mixed capabilities of the analog pins

Here's a capture of 3 successive *IDN? commands. Everything (including tmc etc.)  is default except 'auto 1' and 'addr 23'.

The first command works, the second only returns 'K' and the third works but sounds an error beep.

AR488 GPIB controller, version 0.46.12c, 16/03/2019
KEITHLEY INSTRUMENTS INC.,MODEL 2015,0993190,B15  /A02 
KKEITHLEY INSTRUMENTS INC.,MODEL 2015,0993190,B15  /A02 

[artag]

Here's the same operation with the Girlando code, which seemed to work OK though I haven't compared them in detail

[WaveyDipole]

Thank you for taking the time to record those traces.

These are helpful and sufficient for me to determine that the behaviour is rather different in some respects to what I am getting from my Solatron 7150. For example, there were no state changes on the ATN line, and whereas one trace had the line constantly HIGH, the other showed it constantly LOW. There should have been a couple of transitions (HIGH[idle]->LOW[cmd-address]->HIGH[read data]->LOW[cmd-unadddress]->HIGH[idle]), during each read in both cases.

I will hopefully soon be getting a Keithley 2000 series DMM so I will be able to see what is going on first hand. Hopefully then I can then get the issue resolved.

[artag]

I was concerned about the lack of ATN changes, though I hadn't noticed it was different, only unchanging. I did manage to get it to pulse during a ++loc command (with your code) though so it does seem to be active.

[uslrs]

Hi, I've built the Arduino GPIB interface and connected it to my Datron 1065.  I've fired up EZGPIB and run the debug messages to test the setup.  I know the arduino is on Com9 but the EZGPIB debug message is reporting that Com9 has been opened but no CTS signal detected and thereafter disregards the port.  The AR488 manual identifies an issue with the ch340g chip not asserting a CTS signal and suggests a work around by connecting pin 14 to pin 9 on the chip.  The Arduino I've got is a Uno R3 which uses an ATmega16U2 as the UART-USB adaptor, so is there a similar work around for the ATmega16U2 that will provide a CTS signal?  Many thanks, Les.

[maxwell3e10]

For EZGPIB there is a software-only way to get around the CTS signal problem. See http://www.dalton.ax/gpib/  at the bottom of the page. You have to open the EZGPIB executable with a hex editor and change a couple of bytes.

[artag]

That problem could also be fixed at the arduino end.

From the AR488 manual it doesn't appear to be possible to do the hardware mod, but the code running on the 16u2 is open source and could probably be modified to report a different CTS state. However, you'd need a second arduino to reprogram the 16u2. It would be amusing to do it using the atmega328 on the same board but probably not worth the bricking risk.

[WaveyDipole]

maxwell3e10's post reminded me that I had not yet got around to modifying my EZGPIB.exe binary so having been prompted again I decided to go ahead and do so. According to the paragraph under the 'Notes' heading the first HEX sequence to look for is F6 02 24 10, but my Hex editor could not find this sequence. I checked to make sure that I have the 20121217 version and indeed I have. I looked for the second sequence 24 04 10 0F 95 which the editor did find, so I changed the 95 to a 94. But what about the first sequence? I had another look but the same result. I then tried searching for the sequence 24 10 74 06 (the last two bytes of the original sequence, 24 10, plus the two bytes following, i.e. 74 06) and got a hit, but the two preceding bytes were F6 04 instead of F6 02. Since there was no other ocurrence of the sequence in the file, I went ahead and changed the 74 06 to 75 06 and saved the file. I then tested it with the Nano which has not been modified and the interface was detected on COM8 as hoped for.

Subsequently I looked at the screenshots that are linked at the very end of the paragraph where it says "See here and here." and discovered that in the second image, the sequence to look for is, in fact, shown as F6 04 24 10. There is a typo in the sequence shown in the paragraph. The correct sequence to look for is the one found in the screenshot.

[artag]

Sorry, I made a mistake connecting the logic analyzer for those captures. I had pin 7 connected to REN instead of ATN.
Here are the corrected versions.

[WaveyDipole]

Sorry, I made a mistake connecting the logic analyzer for those captures. I had pin 7 connected to REN instead of ATN.
Here are the corrected versions.

Thank you once again for taking the time and trouble to take another reading of the traces. I could more-or-less make out where the transitions were at the start and end of each read in the previous traces, but now, with the ATN trace present, it is clearly evident that there is an additional transition in the middle of each read. From the original trace characteristics I suspected as much but wasn't sure. In this respect the Keithley behaves differently to the Solatron as it appears to send two lots of data during the read - a short burst and a long burst - instead of just one single burst. During the second read, this longer bust of data is missing on the AR488 trace. I'm not yet sure what this all means and will need to do some further detailed analysis in order to work out exactly what it is going on. The updated traces are very helpful. Thank you.

[WaveyDipole]

Just a quick update.

I now have a Keithley 2000 meter available to the project and so can now confirm that the AR488 is having problems reading from it. While looking at the GPIB section in the user manual I noticed that the meter can be set to 3 different GPIB languages: Keithley 199, SCPI and Fluke 8842. By default this is set to SCPI and always reverts back to this mode after being powered down and switched on again. However, I thought it might be worthwhile to check how it behaves with the other (older) modes. I found that when I selected either the Keithley 199 or Fluke 8842 language, the AR488 did seem to be able to communicate with the meter just fine with all timers set to zero.

Would I be correct in assuming that the Keysight E36312A and the HP53310A (with which the AR488 has also been reported to have problems communicating) also communicate in the SCPI language? If so, then the SCPI language might be the common factor and the next task will be to determine why the interface mis-behaves when communicating in this mode.

[maxwell3e10]

I am surprised that it makes a difference. Nominally SCPI just refers to the syntax of the commands, not the hardware specifications (one can send SCPI commands over RS232 or USB).  On HP53310 I can set  TMD=TML = 0 and TMC = 1000 and it seems to work quite reliably. I briefly looked at the captures posted by artag, it seems there are substantial differences, hard to say which ones are crucial.