AR488 Arduino-based GPIB adapter

[mimmus78]

Anyway thanks for making it. I had it "working" in minutes ... thanks for the good documentation too.

[coromonadalix]

Maybe to help others you could write your solution / code change ??

[mimmus78]

Maybe to help others you could write your solution / code change ??

No solution yet, I'm checking in with the author and sending him some logs ...

[mimmus78]

Log story short, it seems the problem was due to rise time of data lines in my setup or most probably the delay is caused by the GPIB interface of instrument itself. Adding some delay (100us) from the moment pull-up is enabled and the read of digital pins is done itself seems to solve the problem. More details on project GitHub.

[artag]

100us is an awful long time given that the instrument is supposed to assert DAV when the data is there to be read. I'd be interested to see some logic analyser traces of the bus, if that's possible.

[rhb]

My IDC headers and cable connectors *finally* arrived. I'm busy with other stuff right now, mostly in the house cleaning department which has been long neglected.

Here are a couple of photos for an Uno version.  The connectors are not soldered yet.  I just wanted to see how the clearances are with a 90 degree 2x12 header on the Uno side of a board.  It looks as if there is plenty of room.  With a custom shield it will be very easy to make GPIB cables to the exact lengths needed using ribbon cable and IDC connectors and produce a nice professional looking unit.

The cables can be made as a custom fit and if they need to be extended later an extension cable made up with a Centronics female to attach on to the end of the first cable.

[mimmus78]

100us is an awful long time given that the instrument is supposed to assert DAV when the data is there to be read. I'd be interested to see some logic analyser traces of the bus, if that's possible.

The instrument don't check if data pins reached desired logical level ... I'll try to scope some offending pin and check also what's happening as soon as I have few minutes.

[artag]

It's possible the code should set the data lines to pullup when it prepares for data by asserting NDAC. Then they'd have longer to reach their value. However, it does, I think set them to input then : so the bus terminators (should be on every device) should have already done that.

Maybe the ILX LTD-5910 is also a non-conforming interface and doesn't have any. Do you have any other instruments you could put on the same bus ?

[mimmus78]

It's possible the code should set the data lines to pullup when it prepares for data by asserting NDAC. Then they'd have longer to reach their value. However, it does, I think set them to input then : so the bus terminators (should be on every device) should have already done that.

Maybe the ILX LTD-5910 is also a non-conforming interface and doesn't have any. Do you have any other instruments you could put on the same bus ?

I proposed a similar solution to the OP on his GitHub few hours ago, just setting pull-up at the same time of NRFD is asserted ... assuming NRFD and data lines have the same propagation time this should work and will also avoid to add any delay. I don't know GPIB protocol so in deep to understand if this can be done or can cause some problems elsewhere (waiting the author response).

Yes my ILX LTD-5910 is a bicth acting weirdly from time to time when it shares the same GPIB bus. I built this controller to separate him from the other bus ...

Anyway I think that making him working with AR488 can improve compatibility of AR488 with other instruments too (if this can be done without adding strange delays).

EDIT: tested this solution and is working. More details on projects GitHub.

[ogdento]

Don't mean to derail the current conversation, but just wanted to thank everybody involved in the evolution of this adapter.  I wired it up and it instantly worked with my old HP3478 and PM2534 meters... fantastic!

I still have to get it working with a Keithley 197 and a couple of Agilent supplies, but I'm really quite pleased with this.  I plan to build more using some revision of artag's layout, 3-d print some housings, and use one per gpib device (since I don't have any gpib cables).

Really great work, and thanks again!

-Tom

[rhb]

FYI

I hand wired one using an Uno, ribbon cable and 2 IDC Centronics connectors to handle a stacked pair of 34401As.  That's a less expensive way to control multiple instruments.  It cuts the cost from $15/device to $10 + $5/device.  So if you have fewer than 10-12 devices it saves you $10/device.  Not a lot, but if you have a full bus you can get an extra 3478A with the savings.

I finally got the parts after a long wait to make up a version with a 2x12 right angle header.  Once I've verified that, the plan is to layout a PCB for  Arduino shields that use IDC ribbon cable to hook everything up.  With the connectors placed at the exact distances needed, it avoids a big mass of cables behind the instruments.

However, I just bought 4 guitars, so I'll be distracted for a while.  Two arrive Tuesday and Wednesday.  The last was a Martin D-28 in near new condition for reviving my folk music repertoire. It's not yet shipped.  I've been focused on jazz and blues improv so long I've forgotten almost all the tunes I used to play.  But a D-28 should be sufficient inducement to stir up old memories of "Just Like a Woman" and the other stuff I've forgotten.

Have Fun!
Reg

[WaveyDipole]

I proposed a similar solution to the OP on his GitHub few hours ago, just setting pull-up at the same time of NRFD is asserted ... assuming NRFD and data lines have the same propagation time this should work and will also avoid to add any delay. I don't know GPIB protocol so in deep to understand if this can be done or can cause some problems elsewhere (waiting the author response).

.....

EDIT: tested this solution and is working. More details on projects GitHub.

The feedback from mimmus78 has been very helpful and the proposed solution proved to be a good idea. I also had the thought that setting the state of the data bus before every character being sent was unnecessary and would only consume additional CPU cycles, so in the test version the setting of the data bus to input_pullup was done only once before the read loop begins. Testing along with a review of LA traces seems to show no other adverse effects, so the proposed solution to this particular 1st character read problem will be implemented in the next update. Thank you to mimmus78 for reporting the issue and to all concerned for their ideas.

[artag]

Along the same lines, it would also be possible to set the pins in input pullup mode with output values set to zero (assuming that doesn't turn them into input pulldowns - it might) and switch them into output mode for any that need to be pulled low. This emulates an open collector drive. It's both more correct electrically for GPIB and will also execute faster (only one port direction register write instead of a direction and a data register).

However the weak input pullups - although hopefully strengthened by the other terminators on the bus - might be too light and result in too slow a rising transition.
 

[jimmc]

Along the same lines, it would also be possible to set the pins in input pullup mode with output values set to zero (assuming that doesn't turn them into input pulldowns - it might) and switch them into output mode for any that need to be pulled low. This emulates an open collector drive. It's both more correct electrically for GPIB and will also execute faster (only one port direction register write instead of a direction and a data register).

However the weak input pullups - although hopefully strengthened by the other terminators on the bus - might be too light and result in too slow a rising transition.

As you say the original GPIB specification called for open collector drivers and I had  Emanuele's  original design working with this modification.
It would work without enabling the pullups but I don't like the idea of floating inputs (no pulldowns) when nothing is connected so I used a two step method...

Asserted   (Low state)   digitalWrite(xx, LOW); pinMode(xx, OUTPUT) (This way round to ensure output never 'glitches' to +5v)
Unasserted (High state)  pinMode(xxx, INPUT_PULLUP)

Jim
 

[rhb]

@artag,

Here is the header layout on the Uno side of the shield.  Pin 1 is on the top edge of the IDC header.  This will only work with an SMD Uno, but that has a higher source rating than the DIP version, so it is preferable anyway.

Have Fun!
Reg

[WaveyDipole]

I have uploaded an update (0.47.59) which has two bug fixes:

- data bus settling time issue reported by mimmus78
- EOI detection not working (possibly crept in during architecture change between 0.46.xx and 0.47.xx)

Both of these have now been fixed.

In addition, two further Mega 2560 layouts have been added that make use of either row of the end connector. At present, only one layout can be used at a time.

[ogdento]

Hey WavyDipole, did the EOI problem come to you from lmester?  I think that's why his hp3478a program was failing for me, so if it's related I'll grab it!
Thanks,
Tom

[WaveyDipole]

Tom, yes the EOI problem was reported to me by Luke. Please let me know how you get on with it. You will probably need the latest version of Luke Mester's software.

Just a note for everyone else. If you have an older Nano with an old bootloader, then the ++rst command may crash the board. The result will be rapidly flashing LEDs and the board will have to be power cycled. The reason for this is that the older bootloader does not deal with the watchdog properly and ends up going into a restart loop. This was fixed in later versions of the bootloader, so the solution is to simply update the bootloader. This can be done from within the IDE, but will require an AVR programmer or another Arduino board to act as a programmer. There are a number of online resources dealing with using an Arduino board to program another Arduino board.

[ogdento]

Hey thanks for the update - your latest firmware worked great with the latest code from Luke

[pigrew]

I'm thinking about writing a VXI-11 wrapper software for this project, so that GPIB devices could be used through the standard VISA API. However, I have a few questions about the computer side of the driver that I'm hoping someone can answer:

• Is the Arduino Micro the only MCU that can perform flow control so that the MCU's buffers are not overrun (e.g., during large binary transfers)? The Uno seems to have no flow control, so data could be lost if the host sends too quickly?
• Is there a way to receive a status code back after a read or write? It seems like there's no way with the ProLogix commands to know if a write failed, or when the write completes?
• What's the maximum message length? To have longer messages, can I disable EOI/terminators and send multiple shorter messages?

(For those interested, my VXI-11 server is on github)

Thanks,

Nathan

[WaveyDipole]

Nathan, thank you for your interest in the AR488 project. I will try to answer at least a couple of your questions:

Is there a way to receive a status code back after a read or write? It seems like there's no way with the ProLogix commands to know if a write failed, or when the write completes?

An instrument replies with its status code to a serial poll (++spoll). On the Prologix this returns a decimal number representing the status byte. The meaning of the bits does vary somewhat with each instrument maker. However, it seems that you may be looking for a status code from the interface itself to indicate transmission failure or successful completion. In that case, the Prologix commands do not appear to support this, the ++status command being used only to set the status byte in device mode. However, if I can better understand your requirements, then perhaps such a feature could be added.

What's the maximum message length? To have longer messages, can I disable EOI/terminators and send multiple shorter messages?

The interface has a serial capture buffer size of 128 bytes. Since the last byte must be a NULL character, the maximum message length is 127 bytes. Terminator characters including CR and LF can be 'escaped' by preceding them with ESC (0x2B) - see the 'Transmission of data' section of the manual. This would allow such characters to be treated as data when being sent to the instrument. Messages longer than 127 bytes to be sent directly to the instrument by splitting them up into shorter messages, which can then be followed by a suitable terminator and/or the EOI signal. The CR/LF sent to the serial port to signify the end of the line is not passed to the instrument. The termination character sent to the instrument is governed by the setting of ++eos.

If you would like to discuss addition of features to the AR488 firmware, then please feel free to PM me.

[macboy]

I'm thinking about writing a VXI-11 wrapper software for this project, so that GPIB devices could be used through the standard VISA API. However, I have a few questions about the computer side of the driver that I'm hoping someone can answer:

• Is the Arduino Micro the only MCU that can perform flow control so that the MCU's buffers are not overrun (e.g., during large binary transfers)? The Uno seems to have no flow control, so data could be lost if the host sends too quickly?

...

The Micro can use flow control capability because the USB-UART is implemented within the AVR chip itself. On the UNO, Nano, etc., a separate USB to UART chip is used. If you can connect the flow control lines from that converter to the Arduino microcontroller, then the Arudino can monitor/manipulate those lines to implement flow control. This only requires adding a few lines of code to the appropriate HardwareSerial.* files. I have done this on a cheap UNO clone. That clone uses a CH340 UART chip, and the flow control pins are in fact brought out to a separate (unpopulated) 4-pin header on the board (look at the board here, note the solder pads "X1" near the IC near the USB connector). If you only want to prevent the host from overflowing the Arduino Rx buffer, then you only need to use the CTS pin, and use one GPIO on the Arduino. To also allow the PC to stop the Arduino from sending more data, you also need the RTS and another GPIO pin (and to write the associated code, which should be easy).

[artag]

Note that on the micro, the flow control works at the USB level : it does not emulate serial-port hardware flow control.

The Prologix has an actual ftdi chip and manipulates the RTS/CTS pins as described by macboy.

I had thought of emulating the Prologix using the 32u4's USB UART emulation. But I'm not sure it's worthwhile : it's not just a matter of flipping some bits, as the CDC Uart normally used by devices with onchip USB doesn't support CTS. It would be necessary to replace the CDC driver with one that emulates the FTDI or the CH340 and then manipulates the RTS/CTS pins in that emulation.

I'd hope that it's possible to use some of these drivers (either CDC or the hardware USB parts like CH340) to send a continuous stream of data to the GPIB rather than be limited by the buffer. But I haven't looked to see if that's feasible yet. It would only be worthwhile if GPIB devices with large transfers (such as scopes and other screen-based instruments) have to send all the data in one block.

[WaveyDipole]

I have just uploaded the next update, version 0.48.03. This now adds support for the SN75160 and SN75161 GPIB transceiver chips. Two GPIO pins are required to drive the TE control pins on the transceivers and the DC pin on the SN75161, although this can be reduced to one by coupling direction control (DC) pin on the SN75161 to REN, which already provides the required state change between controller and device modes.

There is currently one known issue. With the SN75160 and SN75161 chips placed between the Arduino and the GPIB bus, the ++lon command seems to work a little erratically. The command still works, but seems to miss some characters. This will require further investigation.

With the SN75160 and SN75161 chips in place, an interface can now have the full 48mA current handling available and provide tri-state outputs so that the interface will not cause problems on the GPIB bus when the interface is powered down. I have only tested on a breadboard and with two Arduinos and a DMM, but using these transceiver chips might even allow STM32 "blue pill" boards to be used. Of course, some kind of daughterboard will need to be devised in order to make use of them, but I am sure that suitable shields can be designed for any supported MCU board. I might even have a go at designing one myself....

[bitseeker]

That's really cool, WD. I suppose it'd be possible to make a shield with footprints for several popular uC boards. Really great evolution of this solution.