Adding GPIB bus to custom test gear (hypothetical)

[KSP]

Hypothetically speaking (I say this as I am not currently intending on building this), if I were to build a custom piece of test gear and I wanted to add a GPIB bus to it with a custom set of commands, where would I even start?
I don't really have much knowledge of the inner workings of the IEEE488.2 standard, so what I am really looking for is a pre-built module with maybe a built-in micro which I can load with my command set.
I guess in essence it will be a GPIB-analogue device; receive commands, output analogue voltages etc. but I want something customizable.

Does such a device exist? With USB/serial its relatively simple. I can just send commands from the computer to a micro, and the micro's software will do the rest. But I don't know how I would go about this with GPIB as, if I'm not mistaken, it's a parallel port, and to be quite honest I've had very little experience with anything to do with parallel ports  plus the sheer number of pins on a GPIB connector is a tad daunting compared to the simplicity of serial comms.

Any ideas?

[JS]

What would be the limitation that takes you out of USB? LAN connections would be another option a bit more involved than USB but with it's own advantages, depending on the setup.

JS

[macboy]

There is little value in doing this. You'd be better off to stick with UART or USB (or USB-to-UART). Or, even IP based. It's very easy to set up transparent IP-to-UART bridge with a very inexpensive ESP8266 module.
 
If you are serious about looking into it more, find the HP document "Tutorial description of HP-IB". It gives all the low level details to implement a controller or a device. HP-IB was renamed GP-IB when companies other than HP began to commonly use it, then it was standardized as IEEE488, which was later renamed to IEEE488.1 when IEEE488.2 was created. The latter is a standard set of very basic commands that compliant devices are expected to implement. Devices not implementing the IEEE488.2 commands could still be IEEE488.1 compliant.  Later, SCPI defined a comprehensive command/response structure that was commonly implemented on devices with IEEE488 but actually could use any interface (RS-232, IP, etc.).

[KSP]

What would be the limitation that takes you out of USB? LAN connections would be another option a bit more involved than USB but with it's own advantages, depending on the setup.

JS

Nothing, I'm quite happy using USB for all my home jobs. This was predominant a hypothetical. But, with future projects in mind, at work we still use a lot of test systems comprising of a load of daisy-chained GPIB instrument, and the software we use (Fluke Met/Cal v7) only lets you use GPIB for your reference instruments (although it lets you connect your UUT via other busses). This limitation has been removed in later versions, but we are stuck (for now) with this old rubbish. There are certain workarounds, but I'm just curious about how one would go about manufacturing a GPIB bus

[Pjotr]

In the past there were several universal eurocard makes that handled the GPIB bus at one side and was kind of TTL GPIO on the other side. Not cheap though. It's all quite old and I don't know it is still available.

If you want something to develop yourself today, I would say, a CPLD (Lattice IspMach or so) to handle the bus HW and a MCU on a little PCB. But you must be really in need to justify the effort. Was a long time ago I used Fluke Metcal. It that not LXI compliant nowadays?

[KSP]

... Was a long time ago I used Fluke Metcal. It that not LXI compliant nowadays?

It is... probably. But we don't have the most recent version by a long shot.

It's already sounding like this is gonna be a real pain 😩

[JPortici]

i think the advantage in doing this would be to have a number of instruments communicating over a single bus, where the communication would only be the command you had to insert manully instead and the occasional reading (so not exchanging tons of data like waveforms)
being a parallel bus you could also send triggers and things like that with more precise timing than with a serial bus

what other prodotols could one use instead?

[Kleinstein]

There are USB-GPIB converters. However the usual ones are for a PC with USB to connect to GPIB instruments. Some newer Instruments that come with adapter to opposite way around - so the instrument only has USB interface but can still be used in a GPIB system.

There are quite a few projects that add GPIB to the rasberry and even Arduino. Some of them are USB - GPIB adapters, some in two steps USB - UART + UART - GPIB, where plans and code is available.

Some of the simple/cheap GPIB adapters have weak drivers and thus only work with 1,2 or 3 devices. This could be as little as a small µC with very little extra HW.

In old times there where floppy drives, printers and even a hard drive with an GPIB (or more like IEEE488) interface. For most parts it could be replaced by USB today, except for time critical triggers.

[MarkL]

If this is for test equipment that you are going to sell and support, I would probably start with a GPIB controller chip like the NAT9914 from NI:

  http://sine.ni.com/nips/cds/view/p/lang/en/nid/11153

They aren't cheap and the effort to develop a driver won't be trivial.

If this is a one-shot, I would look to get a cheap PCI (or ISA) GPIB board and put it in a PC with linux.  Install linux-gpib and write a user-land program that listens for controller requests and implements your needed command set.  (Note: Not all boards support device mode - check the linux-gpib manual.)

If your data BW needs are not high, another thing I can think of is the Iotech Micro488/EX.  The Micro488 is a GPIB<-->RS232 converter that can operate in device mode.  It's obsolete, but can be found on ebay.

[KSP]

If this is for test equipment that you are going to sell and support, I would probably start with a GPIB controller chip like the NAT9914 from NI:

  http://sine.ni.com/nips/cds/view/p/lang/en/nid/11153

They aren't cheap and the effort to develop a driver won't be trivial.

If this is a one-shot, I would look to get a cheap PCI (or ISA) GPIB board and put it in a PC with linux.  Install linux-gpib and write a user-land program that listens for controller requests and implements your needed command set.  (Note: Not all boards support device mode - check the linux-gpib manual.)

If your data BW needs are not high, another thing I can think of is the Iotech Micro488/EX.  The Micro488 is a GPIB<-->RS232 converter that can operate in device mode.  It's obsolete, but can be found on ebay.

Thanks, I hadn't thought of that! As far  as I know, the NI GPIB interfaces support device mode (not that I know how to do it though...). This is certainly worth looking into for what I want.

And no, I am not making devices for sale, they will indeed be one shot deals

[KSP]

Just to add... I know the NI ones are not exactly cheap, I just happen to have a couple lying around 

[dom0]

GPIB on the hardware level isn't very complex, conceptually. Every machine implements a small state machine,  and all these state machines are directly coupled together via discrete logic lines on the bus. Super simple.

What makes it complex is that the "specification" (including timing!) of all the state machines have to match very well or you are going to get very hard to diagnose problems. Additionally the standard isn't exact on some things (like when an transmission ends), which also adds some complexity. 488.2 also adds a good pile of complexity to implement.

So while it's relatively easy to implement a GPIB interface using 74xx logic (and this is how it was done in the 60s and 70s, many of these instruments don't have a processor in them), it's hard to do it correctly, interop is the main concern.

Overall... there are ways to get there quicker. VXI-11 is essentially GPIB-over-TCP...

[nfmax]

Hypothetically speaking (I say this as I am not currently intending on building this), if I were to build a custom piece of test gear and I wanted to add a GPIB bus to it with a custom set of commands, where would I even start?
I don't really have much knowledge of the inner workings of the IEEE488.2 standard, so what I am really looking for is a pre-built module with maybe a built-in micro which I can load with my command set.
I guess in essence it will be a GPIB-analogue device; receive commands, output analogue voltages etc. but I want something customizable.

Does such a device exist? With USB/serial its relatively simple. I can just send commands from the computer to a micro, and the micro's software will do the rest. But I don't know how I would go about this with GPIB as, if I'm not mistaken, it's a parallel port, and to be quite honest I've had very little experience with anything to do with parallel ports  plus the sheer number of pins on a GPIB connector is a tad daunting compared to the simplicity of serial comms.

Any ideas?

How about using a Keysight/Agilent/HP 34970A datalogger, with the appropriate modules? This has GPIB, is IEEE 488.2 compliant, is still in current production, and is readily available second hand. Although it's presented primarily as a datalogger, there are modules with uncomitted relays (crossbar, medium power, and RF switching), and a general-purpose module with two DACs and 8 bits of high current digital output, as well as various inputs. You can install up to 3 modules of any mix of types. They are pretty easy to program over the GPIB.

If you don't need the measurement capabilty, option 001 omits the DVM for a small saving. But you may find the measurement capability useful for your requirement.

[doktor pyta]

I found nice module for that purpose for $60.

'GU01 GPIB to UART Module is a GPIB device interface module. It is designed for equipment. If you have a UART port on your system and you would like your system to be controlled by GPIB controller, then this is for you.  The module can be Listener and talker.
The standard GU01 module is powered by 5V DC power supply, very easy for use. The GPIB address can be set from 0 to 30. There are two UARTs on the module. One for communicates to your system. Another one is a UART port. You can set the module as UART to UART and UART to GPIB communication.
The module for sell is pre-programmed GPIB to UART adapter module.  The programmed module has a fixed GPIB address, which has been set to be 18. The data speed has been set to be 9600bit at first UART (UART1), which can communicates to your system. Second UART (UART2) does not work on the programmed module.
For detailed information, please refer to the module datasheet and user’s manual at,
http://www.lqelectronics.com/support/GU/download.html
Again, GU01 is a listener and talker, not a controller. It is GPIB device interface to UART adapter module.  '

http://www.ebay.com/itm/GPIB-to-UART-Module-Made-in-USA-/281936297941

[KSP]

That actually does look very much like what I am after! Thank you. My projects are all on hold while I sort out family stuff but I will post results if and when I get round to doing something with it