GPIB interface (IEEE488)

[WaveyDipole]

I have recently purchased a digital meter with a GPIB interface. I have been looking at how to connect the meter to a PC to explore programming it, but I have found that the GPIB adapters cost as much as the used meter! Strangely, there also seems to be a complete lack of the usual far east 'alternatives'. Does anyone know if there is a cost effective way of building a GPIB interface?

[CatalinaWOW]

LQ Electronics sells a cheap one.  Not a lot more than you would pay for the parts for a home brew version. 

Here is a link to a roll your own approach

http://www.edn.com/design/test-and-measurement/4318969/Build-a-USB-based-GPIB-controller

[plesa]

If you do not have GPIB adapter you can build GPIB from Arduino.
http://egirland.blogspot.cz/2014/03/arduino-uno-as-usb-to-gpib-controller.html

[bingo600]

LQ Electronics sells a cheap one.  Not a lot more than you would pay for the parts for a home brew version. 

Here is a link to a roll your own approach

http://www.edn.com/design/test-and-measurement/4318969/Build-a-USB-based-GPIB-controller

That's an Old design , Don't ....

Either get a "Clone Agilent/NI USB adapter" , or for a tryout make this one (costs an arduino)  , the GPIB connector is more expensive than the arduino.
https://egirland.blogspot.dk/2014/03/arduino-uno-as-usb-to-gpib-controller.html

Edit: Damm beaten by Plesa   
/Bingo

[plesa]

LQ Electronics sells a cheap one.  Not a lot more than you would pay for the parts for a home brew version. 

Here is a link to a roll your own approach

http://www.edn.com/design/test-and-measurement/4318969/Build-a-USB-based-GPIB-controller

That's an Old design , Don't ....

Either get a "Clone Agilent/NI USB adapter" , or for a tryout make this one (costs an arduino)  , the GPIB connector is more expensive than the arduino.
https://egirland.blogspot.dk/2014/03/arduino-uno-as-usb-to-gpib-controller.html

Edit: Damm beaten by Plesa   
/Bingo

If you want I have box of blue GPIB connector in my garage, I can ship them for shipping cost or small donation to charity
I made quite good GPIB cables out of it.
Check this thread
https://www.eevblog.com/forum/metrology/raspberry-pi23-logging-platform-for-voltnuts/new/?topicseen#new

[guenthert]

LQ Electronics sells a cheap one.  Not a lot more than you would pay for the parts for a home brew version. 

Here is a link to a roll your own approach

http://www.edn.com/design/test-and-measurement/4318969/Build-a-USB-based-GPIB-controller

Uh, you might want to avoid the UGSimple model though.  No better than the self-made ones (might have difficulties driving multiple or old devices, mine at least does).  Can't speak about the Windows software, but the one for Linux is among the worst I've ever encountered.

I ended up buying a cheap PCI based pre-enjoyed one (with CEC chipset) of e-bay.  That one works fine with the linux-gpib library.

[bitseeker]

There are three models of the LQ interface. Here's a comparison table. The UGSimple and UGPlus do not have line drivers and, as a result, cannot support many devices on the GPIB bus.

More importantly, if you ever want to use the interface with standard GPIB control software, the LQ interfaces use proprietary libraries and won't work without recompiling. For tinkering, the Arduino solution may be the best way to get started, especially if you already have one lying around.

Model	Max. command/data length	Binary data transfer	Screen image capture	GPIB script feature	File read and save	Max. GPIB devices	Hold screws
UGSimple	60	No	No	No	No	<5	No
UGPlus	20,000	Yes	Yes	Yes	Yes	<5	No
UG01	20,000	Yes	Yes	Yes	Yes	14	Yes

[mmagin]

If you have more time than money, or if it's a fascinating project to you:

First, if you can put the instrument in talk-only mode (certainly possible with older HP DMMs) where it just spits out the readings at the rate it's triggered at, I believe you can hook a 5V-tolerant microcontroller (e.g. AVR/PIC) to the 8 DIO lines and the DAV line and cobble together a listen-only interface pretty easily.

Going a little bit further than that:
https://egirland.blogspot.com/2014/03/arduino-uno-as-usb-to-gpib-controller.html

[WaveyDipole]

As it happens, I have one of those Arduino UNO kits now waiting for a real world project. I will probably prototype it first using the kit and then use a far east clone for a more permanent solution. I have PM'ed you, plesa, about those GPIB connectors.

I do also have an FT USB serial adapter somewhere although I would have to dig it out and check that it is suitable for this project. I do know it was TTL 5v as I used it to control the shutter on my old camera. However, I tend to agree that the Arduino option might be the easiest to get started with.

Incidentally, I also have a Rigol 1054Z and have their UltraSigma and UltraScope software installed. The former is a communications framework which allows screen grabs and talking to the instrument interface manually and it works well over USB or LAN. However, it also has a GPIB and RS232 option. The GPIB option allows for the setting of a serial COM port for comms. I was wondering whether once I have a USB-to-GPIB hardware set up, whether it would allow me to talk to a non-Rigol instrument at least at rudimentary level?

[amspire]

That Arduino Uno gpib project is brilliant!. Just tried it with an Arduino Deumilanove and it worked first time.

I didn't have a connector, so I cut a gpib cable in half. I have a couple of those $3 CH340 Arduino boards on order and I will use the cable to make two gpib controllers.

Just finished trying it out with a HP 33120A waform gen. and a Time 9811 programmable resistance. All the commands I tried worked.

The cable cost me $10 and so that works out at about $8 per gpib controller.

[bitseeker]

That was quick, amspire. Congrats on your nearly instant, low-cost GPIB controllers and thanks for sharing your results.

[amspire]

Just thought I would add some notes about my experience at building the Arduino Uno 6.1 GPIB interface.

http://egirland.blogspot.com.au/2014/03/arduino-uno-as-usb-to-gpib-controller.html

It is probably better getting the files from github, as you get the documentation as well in the zip file.
https://github.com/larsks/arduino-gpib

The code runs fine on my Deumilanove board, and as mentioned before, I just cut a GPIB cable in half for the connection. I secured the cable with a tie through one of the mounting holes and tacked the tie to the cable in a few spots with the soldering iron to stop the cable from rotating. The board I used was a cheap Arduino clone, but with with real FTDI chip. Any working RS232 interface chip should work.

Get the Prologix manual to get some extra documentation on the ++ commands.
http://prologix.biz/downloads/PrologixGpibEthernetManual.pdf

The Serial Monitor built into the Arduino IDE is fine for testing.

Initially, use verbose mode ("++verbose"). The first command you must do is to set the correct GPIB target address. If the target device has the address set to 13, use "++addr 13". Many devices will want the EOI (end of information, I guess) to be enabled - "++eoi 1" .

If you send a command requesting information, you will need to follow it with a ++read command. If you enable auto mode ("++auto 1"), it will automatically do reads after every command, and so you will get errors whenever the command has no return data. These errors are usually benign.

The project is designed to talk to just one GPIB device, but one of the users has controlled 3 devices connected to the Arduino. It can overheat the ATmega324P chip, particularly if it is a small form factor chip.

Last time I checked, the price of getting a PCB mount right angle male 24 pin Centronix connector for use as the GPIB connector was pretty high. Cables are much easier to get and they give you two connectors.

Richard.

[bitseeker]

Thanks for sharing your notes, Richard. Nice job with the wiring! When you receive those other Arduino boards, do you plan to add some driver chips or transistors to handle the load of the bus/devices?

[Johnny10]

I see you are not in the states... this may not be for you with customs and taxes?
but I just bought an NI PCI-GPIB card that worked first time I plugged it in.
It found different test equipment pretty quickly. I connected 7000 series TEK scope and HP 8903.

Total cost including shipping $45.00 I see others available similar prices.

I have been looking for these cards for a year now and they have always been over 150 dollars.
Glad they are getting cheaper.


http://www.ebay.com/itm/National-Instruments-PCI-GPIB-IEEE-488-2-PCI-Card-tested-/262871248479?hash=item3d3458ee5f:g:wZgAAOSwj85YPGd2

[amspire]

Thanks for sharing your notes, Richard. Nice job with the wiring! When you receive those other Arduino boards, do you plan to add some driver chips or transistors to handle the load of the bus/devices?

Probably not. I like the idea that you can do gpib with just an Arduino and connector or cable. Unfortunately, even though this project is open source, it is a CC Nonderivative license. In other words, even though it would be dead easy for people in this forum to extend the functionality, no-one can share improved versions.   

I am just going to use it as is, and if I want serious gpib, I will go and get an Agilent or Prologix device.

[amspire]

I see you are not in the states... this may not be for you with customs and taxes?
but I just bought an NI PCI-GPIB card that worked first time I plugged it in.
It found different test equipment pretty quickly. I connected 7000 series TEK scope and HP 8903.

Total cost including shipping $45.00 I see others available similar prices.

I have seen lower prices. I actually had an ebay ad on my browser for an A$77 PCI GPIB card when I read your post. Trouble is it has to run from a desktop PC.

One of the good things about this Arduino gpib is that as well as working with notebooks, it can easily be controlled by a low cost, low powered device like an OrangePI zero, or Raspberry Pi. It just means you can cheaply set up a long term monitoring of, say, voltage references without involving PC's.

[WaveyDipole]

Vendor must have put the price up since its now 60$.....

Although it is one option, I'm not keen on a PCI card as I would preferably like to use the laptop. Interesting point about the CC Nonderivative license. Presumably it does not prevent me from improving it for my own purposes then? Its a shame that any improvements cannot be shared. The expresses my thoughts on that as well.

[bitseeker]

Correct, you can do whatever you want with it for your own use. You just can't distribute your improved firmware. Of course, you could contact the author about pulling your changes into the main code base. That could still benefit the community.

Failing that, you could post about what you did to improve it. We're keen on reading about it.

[mmagin]

Somewhat related to this, I have also wondered if a good route to a reliable GPIB interface is to use one of these NI GPIB-232CV adapters you find on ebay with any old USB-serial adapter.  It's old and fairly cheap, but you're not locked into something like ISA or PCI.

I'm less interested in specific drivers or anything, I like stuff I can just open a connection to better than stuff that uses a wonky API (which is why I find myself liking the Prologix stuff much more than the classic Agilent, NI, etc. stuff supported by Linux GPIB).

[bitseeker]

That's an interesting idea. I don't see why it wouldn't work for normal control purposes, as long as the USB-RS232 adapter works well (some can be flaky).

[amspire]

Correct, you can do whatever you want with it for your own use. You just can't distribute your improved firmware. Of course, you could contact the author about pulling your changes into the main code base. That could still benefit the community.

Failing that, you could post about what you did to improve it. We're keen on reading about it.

What I am working on right now is running Emanuele Girlando's Arduino GPIB board from a OrangePi One PC board. The board is running 16.04 Ubuntu with a lightweight XFCE desktop interface via TightVNC. I just love the idea of a computer + GPIB that uses less then 2W. I have a UPS that could easily run this along with a DVM for about 10 hours from the battery, so it makes sense for getting good uninterrupted logging.

So right now I am concentrating on setting myself up to do Python coding on the OrangePi to talk to the Arduino GPIB. Tried some quick serial code, and it is hanging - have to debug that.

The tools that run well on the OrangePi include the Arduino IDE, Geany (Python IDE), Glade (if I want to make any GUI for Python).

IDEs like Eclipse and PyCharms absolutely kill the computer with RAM usage.

Looks like I am going to bite the bullet and learn how to use Vim (gulp) as a Python ide. Very powerful, and it just flies on the low powered OrangePi. In typical Vim practice, I have had to recompile Vim to add all the features needed for IDE use, I have had to sort out a .vimrc that makes it possible to read comments (by default dark blue) on the black terminal screen background, and I will next have to learn how to do plugins (complex - but can be simplified with even another plugin). I am always using vi or vim, so I may as well learn how to use it properly.

I guess it is possible to make some changes to the Arduino GPIB code as long a it is the form of patches that can be added to the original code. The features I would like to add include SRQ (I think someone has already published code for this) and "++read EOI" so I can efficiently read a multi-line response from an instrument. It shouldn't be that hard to implement the "++read (char)" functions as it just means to continue to read lines until you get the character (char) from the instrument.

Richard

[bitseeker]

Low-power servers are really cool. I've been running a PogoPlug with portable external drive at home for a file server for a while now. Although I haven't measured the setup, it's really low power consumption, too.

[amspire]

Making progress. Finally got my Python code running on my OrangePI to reliably talk to the Arduino GPIB. After powering up the Arduino, the first communication always failed, but if I used a terminal, it always worked first time.

I had the scope out, then the logic analyser which all showed no problem at all.

Finally worked out that the Arduino Duemilanove has the lovely property that before you connect to the serial port, the DTR is 5V. The first time you connect to the USB serial port, the DTR goes low which resets the Arduino via a capacitor coupling. Stays low after that.

The reason why the terminal always worked was I always took more then 1.5 seconds to send a command after opening.

I gather the FTDI rs232 behaviour is well known - I just didn't know.

I guess the CH340 boards I have on order will do the same thing. It is OK - just needs a 2 second delay after opening the serial port - but it probably means I should just leave the port open all the time while the python code is running.

I may do some changes to Emanuele's code and I will just use Linux diff and patch to record the changes to get around the NoDerivative license. Is that legal?

Here is the words from the CC nonderivative license:

NoDerivatives — If you remix, transform, or build upon the material, you may not distribute the modified material.

It is OK to freely distribute unmodified CC NoDerivative-licensed source code. Not sure about a diff file that can modify this source. Any opinions?

I have got my up-to-date Cygwin diff and patch for use on Windows, but the other thing I discovered is I had to rename patch.exe, since if a program contains the word "patch", Windows insists it has to be run under administrative permissions. If you rename any program patch.exe or somethingpatch.exe, it will suddenly only run under Administrative permissions. If it is renamed to pa_tch.exe, it is fine.

[jimmc]

I have used Emanuele's code with an Arduino Nano (CH340 clone), I got over the DTR reset problem as below. (Crude but it works for me).
The logic levels and drive capability are not within specification but I have tried it with older instruments using the Texas and Motorola chipsets without problems. (Only one at a time)

OK it's not a guaranteed solution but for a total cost of a few GBP I'm happy.

One other thing I didn't like about the code was that the GPIB lines were driven high see comments from my code below.

// Modified to use 'Open Collector Mode' to follow GPIB specification...
// 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), High by internal pullup only (20-50 kOhm)
 
// Arduino Nano clone using CH340G.  CTS & DSR lines asserted by grounding pins 9 & 10 of CH340G (needed for compatibility)
// 100 ohm from Arduino RST to 5v via jumper. Inhibits DTR reset starting bootloader.
// Also incorporates Florian's comment.
// ++ver reply changed to "Girlando GPIB-USB Controller modified version 6.1.1"

It's now recognised by EZ-GPIB and KE5FX GPIB Toolkit but I have not taken this any further.

Unfortunately the RF Scientific GPIB Logger v 1.0 from doktor pyta looks for the VID&PID of a FTDI device and does not work. This was the one I really wanted

Pity about the no Derivatives licence.

Jim

p.s.
I know there is a high speed version of the GPIB spec that uses 'active high' drivers but for low speed devices like this it's much safer (for the instrument) not to use this mode.

[macboy]

Be careful with these Arduino based GPIB adapters, they do not meet the electrical (layer 1) requirements for GPIB. The spec says that a logic high can be as low as 2.0 V, and because of the thevanin termination, it will actually never be higher than about 3.3 V on Tri-state open-collector systems, i.e. nearly all of them. The 2.0 V spec is fine with TTL input devices, but the Arduino has only CMOS inputs. That means that a logic high (with 5 V Vcc) should be presented to the input pin as > 0.6*Vcc or > 3 V. and a logic low should be < 0.4*Vcc or < 2 V. (To get even more specific, look at the Atmega328P datasheet, graphs for "Input Pin Threshold and Hysteresis"). It may work, but is certainly not guaranteed. A better idea is a micro with TTL inputs, either fixed or configurable.  Besides the logic level problems, there is also the need for 50 mA of current sink per line. You can kind of get around this issue by only loading the bus with a single device (more devices = more terminations to sink current from).

[amspire]

Current is the one thing I am not concerned about. The 50ma rating drives 14 devices at high speed on a 20 meter cable. The Arduino is usually driving 1 device on 0 metres of cable at low speed  and it can comfortably drive 20ma. In practice, my Arduino is using less then 20ma in total  when talking to a gpib device.

I will hook up the  oscilloscope and logic analyser and compare the Arduino to the specs. I am going to assume that the Arduino is closely connected to at least one device with the proper termination. See what can be done.  Going to proper driver chips does mean the addition of 200ma of current, a PCB and ICs that cost more then the Arduino clone.

My Arduino is working reliably on the 3 devices I have on hand, so my only concern is "is it safe?".

[bitseeker]

Yeah, safe for all the devices involved. Looking forward to your findings, Richard.

[bitseeker]

Here is the words from the CC nonderivative license:

NoDerivatives — If you remix, transform, or build upon the material, you may not distribute the modified material.

It is OK to freely distribute unmodified CC NoDerivative-licensed source code. Not sure about a diff file that can modify this source. Any opinions?

IANAL, but it seems that patches are not addressed. The license is about the original code. My understanding of the spirit of the license is that it's to be used when the author doesn't want his name and/or software associated with derivatives over which he has no influence nor control. Whether or not distributing the original as-is along with diffs keeps with the spirit of the license, I suppose it does to the extent that it disconnects the association somewhat. More separation could be achieved by not distributing the original, but documenting in the diff where to get the original to which the diff can be applied.

Of course, one could still contact the author to propose adding the changes to the code base. If he pulls them in, it'd be less hassle.

[amspire]

Yeah, safe for all the devices involved. Looking forward to your findings, Richard.

Just had a quick look at the IEEE488 specs. The maximum  voltage out from any pin should be 3.7V no load. Now it should be possible to make the Arduino outputs behave like open collector outputs as Jim (jimmc) described. If the Arduino high outputs are switched to just the >20K pullup, then the maximum high voltage you would get on a closely connected (ie the adapter plugged into the instrument directly) would be 3.5V.

Looks like the recievers should be rated to accept 5.5V or less, so the current implementation of the outputs is not a disaster - just way out of specs for IEEE488.

Anyone could add the 3k+6K2 resistors on every output if they want - just in case they need to use a cable, but I do not want to.

[amspire]

Here is the words from the CC nonderivative license:

NoDerivatives — If you remix, transform, or build upon the material, you may not distribute the modified material.

It is OK to freely distribute unmodified CC NoDerivative-licensed source code. Not sure about a diff file that can modify this source. Any opinions?

IANAL, but it seems that patches are not addressed. The license is about the original code. My understanding of the spirit of the license is that it's to be used when the author doesn't want his name and/or software associated with derivatives over which he has no influence nor control. Whether or not distributing the original as-is along with diffs keeps with the spirit of the license, I suppose it does to the extent that it disconnects the association somewhat. More separation could be achieved by not distributing the original, but documenting in the diff where to get the original to which the diff can be applied.

Of course, one could still contact the author to propose adding the changes to the code base. If he pulls them in, it'd be less hassle.

I would contact Emanuele. I have already donated some money to him for his efforts. The diff only works if you have exactly the right version of the source, but it would be possible to host the source at one place, and distribute the diff separately.

The author is talking about a V6.2 coming out, but it does look like changes are needed right now.

There is a potential copyright issue with diffs in that they will contain a number of lines from the copyright code. It would be possible to come up with a solution that just replaced every changed line and inserted new lines and the differential update file would have no copyright code from the original. Take a bit of scripting to implement it.

[JXL]

How about just posting the changes/edits as a reply to Emanuele's blog?  Instead of dealing with the license issues, I did just that with handling the SRQ feature.  That way the source and changes are in the "same place".  Just my $.02

[amspire]

How about just posting the changes/edits as a reply to Emanuele's blog?  Instead of dealing with the license issues, I did just that with handling the SRQ feature.  That way the source and changes are in the "same place".  Just my $.02

Thank you for that SQL code - I will take a look.

Could do it that way, but you were just doing a small addition. Not sure how you would post a major change in the forum. Just for example, if someone wanted to convert it from a dedicated controller mode to controller and device mode, it would probably mean big changes to Emanuele's code. You would need to post the entire revised source code on the forum, but you cannot - that would break the license.

[macboy]

Yeah, safe for all the devices involved. Looking forward to your findings, Richard.

Just had a quick look at the IEEE488 specs. The maximum  voltage out from any pin should be 3.7V no load. Now it should be possible to make the Arduino outputs behave like open collector outputs as Jim (jimmc) described. If the Arduino high outputs are switched to just the >20K pullup, then the maximum high voltage you would get on a closely connected (ie the adapter plugged into the instrument directly) would be 3.5V.

Looks like the recievers should be rated to accept 5.5V or less, so the current implementation of the outputs is not a disaster - just way out of specs for IEEE488.

Anyone could add the 3k+6K2 resistors on every output if they want - just in case they need to use a cable, but I do not want to.

One absolutely must emulate open collector outputs for a GPIB interface. The 5 control lines in particular are not compatible with active-high driven mode of operation. Trying to drive these high would result in similar problems as a I2C device trying to drive lines high. It doesn't work properly because it contradicts the protocol. For example, a I2C master that drives the clock high may work with many devices, but will suddenly fail to work with a slave device that uses clock stretching.

On most microcontrollers, including the Arduino's Atmega328P, you can emulate OC outputs by setting and leaving the output state to 0 (low), then toggling the pin between output (drive low) and input (float high).

[amspire]

One absolutely must emulate open collector outputs for a GPIB interface. The 5 control lines in particular are not compatible with active-high driven mode of operation. Trying to drive these high would result in similar problems as a I2C device trying to drive lines high. It doesn't work properly because it contradicts the protocol. For example, a I2C master that drives the clock high may work with many devices, but will suddenly fail to work with a slave device that uses clock stretching.

On most microcontrollers, including the Arduino's Atmega328P, you can emulate OC outputs by setting and leaving the output state to 0 (low), then toggling the pin between output (drive low) and input (float high).

You are right that we should emulate the OC output, but the consequences of driving high are not as bad as you would think. Any time the lines are driven high, no other device should be pulling low - that is the theory, anyway. Also, GPIB inputs are rated to handle 5V, but under 4V is better.

The reasons for going OC with all the lines are that it makes the Arduino immune from damage if another device is pulling low at the wrong time (maybe a device misbehaves on startup or shutdown), and also that speed is not the issue. The serial port in at 115200 baud which is just over 10,000 bytes per second. That is the maximum speed you can get out of this device, so active pullups are definitely not needed for speed. The code actually has liberal 10, 20 and 30 microsecond delays everywhere, so I think Emanuele decided that with about 100uS per byte maximum speed, he could be generous with delays for settling time without affecting speed much.

I am definitely going to test OC-type outputs, and I also have also hooked a logic analyser up. I can see a few odd things that probably will not affect it working, but just do not look right. Overall though, the traces look excellent.

Also I have taken the baud rate up to the maximum for a 16MHz Atmega328 of 1000000 baud on my Arduino and it works! There could be some hope of speeding this up. To get any GPIB speed improvement, I have to start reducing the built-in delays.

Richard

[amspire]

Just ordered a bunch of Arduino Pro Micro boards (9 for A$25.56) using the ATMega 32U4 chip. The different port allocation will definitely need a change to the UNO GPIB code, but the huge thing is the USB is on chip, so it actually doesn't care what serial speed you connect at - it always runs faster USB speed then the Arduino + serial chip combo can manage. The normal Aliexpress price is about A$4.

http://www.apcc.tk/news/arduino-pro-micro

[amspire]

The 24 pin male PCB GPIB tend to be hard to locate (hard to know what to search for), so here are some links. If anyone has a cheaper source (Aliexpress, etc) please post them:

http://au.mouser.com/ProductDetail/NorComp/112-024-113R001
http://au.mouser.com/ProductDetail/TE-Connectivity-AMP/5552741-1
http://www.digikey.com/products/en?keywords=1024RMA-ND
http://www.digikey.com/products/en?keywords=A31843-ND

There is a Fuyconn 57RR series 24 pin connector, but I do not know a source.
http://www.fuyconn.com/products_detail1/productId=474.html

[bitseeker]

Thanks for those links, amspire. The connectors are 24-pin, Centronics type. DigiKey seems to have quite a variety of them, though some are obsolete. Here's a list of the right-angle, through-hole versions in both genders that are listed as active:

http://www.digikey.com/products/en/connectors-interconnects/d-shaped-connectors-centronics/438?k=&pkeyword=&pv1989=0&FV=114016f%2C1140215%2C160001d%2C1680002%2Cffe001b6&mnonly=0&newproducts=0&ColumnSort=1000011&page=1&quantity=1&ptm=0&fid=0&pageSize=25

[amspire]

Did a quick test with the pins changed to OC (open collector) mode and as expected, the adapter still works fine. There is no need for any active pull-up. Fall time is not an issue - something like 10ns. Rise time was 0.3us and if I add termination resistors on the adapter, this will drop to 0.15us. This will be completely adequate.

Richard

[amspire]

Just attached an example of the Arduion Uno GPIB with a quick mod to make it OC outputs - none of the outputs are driven high any more. The time taken to set the data lines is simply that my OC mod is setting each data line seperately.

This is an *IDN? request of an HP 33120A AWG.

If you want to understand it, the Talker puts the byte on the data lines. The names might be confusing - the bus uses negative logic so Low = True. The Talker waits until all the Listeners have set the NRFD (Not Ready for Data) High to indicate everyone is ready, and then it pulls the DAV (data available) low to tell the Listeners that a new byte is available. As soon as this happens, the Listeners pull the NRFD low again to indicate they are processing the data, and set NDAC high when the data has been accepted. When all the Listeners have accepted the data, the Talker sets the DAV high again and starts loading the next byte to the Data lines.

A nice thing about this bus is there are very few parts of the protocol with critical timing. In general, the whole conversation between Talkers and Listeners can slow down to whatever speed the slowest device can manage. With Emanuele's code, the adapter only runs at about 1/100th of the old IEEE488 maximum speed, and 1/800th of National Instrument's High Speed modification of the standard. It sounds bad but most GPIB instruments cannot achieve full speed and do not need to have much speed.

The *idn? request to the 33120A:


The reply back from the 33120A:

[jimmc]

Ebay UK source of  connectors http://www.ebay.co.uk/itm/Centronics-Plugs-Sockets-PCB-Ribbon-Cable-R-A-Mount-14-50-Way-EB67-1-piece-/391507935311?var=&hash=item5b27b1004f:m:mL3rRc-lMiIx-rItIkYt3Ig.
I used the straight PCB connector (with wires) which made the adaptor small enough to plug straight onto the test gear.

Re logic levels, extract from MC3447 attached, typical output high is 3.5v.
As I said in my first post, no guarantees but it has worked for several people so far and is by far the cheapest solution so far.
Now if only doktor pyta would modify his code...

Jim

[amspire]

The MC3447 is half the supply current of the SN75160/75161 chips, but it seems to be very hard to get. The few stockists seem to be charging a lot of money.

Interestingly, looking at some photos of 2005/2007 Prologix boards, it looks like they are directly connecting ATMEGA ports straight out to the GPIB connector - no driver chips. I do not have photos of their latest products but they quote 100mA maximum supply current. Given the current needed to power the bus, they probably are still not using any GPIB bus drivers.



The IEEE488.1 spec says the drivers have to sink 48mA at 0.5V. Looks like the 2007 Prologix used Atmega16A family chips that can manage about 24mA out at 0.5V from the ports. The Atmega328P can manage about 18mA at 0.5V.

As I mentioned, the 48mA only matters if you are driving 14 devices on 20 meters of cable. If you are driving 3 devices on 2 meters of cable, 18mA would be overkill. The equation for any of the output ports is basically 1.6mA maximum per listening device plus whatever extra you need to drive the cable capacitance.

Edit: The Prologix was discussed in this thread: https://www.eevblog.com/forum/chat/prologix-gpib-usb-controller/
Looks like it might be an ATmega164P chip.

[WaveyDipole]

I have just found a UK source of an in-line plug. There is no mention of IEEE488 or GPIB so it doesn't come up in searches. RS are currently not charging for postage.
http://uk.rs-online.com/web/p/general-purpose-rectangular-connectors/2391207/

[amspire]

I have a couple of the PCB connectors from Mouser on order along with some mini Arduino boards coming from China. Mouser were as cheap as anywhere else.

I am particularly keen to try out the Leonardo-style mini boards with the superior serial protocol - up to 2,500,000 baud regardless of the port baud rate settings. Probably will not do any more till I get them, but I was thinking about using classes to implement a GPIB state machine that exactly follows the IEEE488.1 spec that is specified in terms of state machines. It is the only way I can think to exactly follow the standard without a massive amount of work. Could easily be slower then Emanuele's version, but it might work.

It will need some changes - to be able to run in the non-controller mode, the ATN and EOI have to be implemented using interrupts to get the needed speed. You would think the SRQ should be an interrupt, but there is no need for it to react quickly. The SRQ just waits there till the software gets around to handling it.

If I succeed, I will release the code under the MIT license. I really like that license - "do what you like, but don't blame me".

Emanuele's version is really excellent as is. He has really put a lot of great work into this project. It will probably handle most needs and it works just as well if you turn all outputs to Open Collector type outputs. For the moment, I have put my Duemilanove in a cardboard box and that will be my USB to GPIB converter till I get the new hardware.

Richard

[bitseeker]

Wow, 2.5M baud. I have not worked with those boards before. Should be interesting.

"do what you like, but don't blame me"

Sounds like a good license to me!

Oh, and it looks like GPIB interface prices on eBay are recovering.

[Johnny10]

So I should have bought two ?

[bitseeker]

Maybe. Reselling the second could've paid for the first. C'est la vie. It's like stocks. You just never know what'll happen.

Meanwhile, if you need another interface, you could give the Arduino project a try.

[WaveyDipole]

I have completed building my GPIB interface. I was able to source the 24 way plug from RS and a 2m length of cable by purchasing an old parallel printer cable from a market stall. Finally the Arduino board came from eBay. The total cost was 12.47GBP.

I have tried it today and unfortunately it doesn't work for some reason. Having confirmed that the address is set to the deafult of 23 and connecting up the interface cable I used PUTTY on Windows to make the connection manually. I do get the reposnse from the ++ver command:

Code: [Select]

ARDUINO GPIB firmware by E. Girlando Version 6.1
However, I am not 'seeing' the HP3478A. For example, I get nothing on the meter when I try to run:

Code: [Select]

OUTPUT 723;"D2Hello"
Enabling ++verbose mode I get:

Code: [Select]

> gpibWrite: timeout waiting NDAC
set_comm_cntx: gpib write failed @1
gpibTalk: set_comm-cntx failed.

>

So I checked all of the wiring to ensure that each wire is connected to the correct Arduino output. I checked continuity on all wires. I then connected a Logic Analyzer to the DAV, NFRD and NDAC lines to observe the handshake and got absolutely nothing. Thinking that my Arduino board was faulty, I then unplugged from the instrument and uploaded a basic LED blink sketch. By changing the pin number and re-uploading the sketch, I was able to confirm that each pin was being pulled up and down and the board is therefore working correctly.

I am therefore at a loss to explain why I am getting no output with Emanuel's code either with the instrument connected or not.

[JXL]

Verify REN is connected to signal ground.
And set the listener's address with "++addr <listener address>"

[plesa]

Send to Arduino GPIB adapter this commands ++addr [address]  and  ++auto
If it will still not respond try to send to instrument "END ALWAYS"

[WaveyDipole]

Thanks for the replies . In had, in the meantime, enabled debug mode in the code so as to get more information about what was happening and also realized that the interface was coded to send to address 2 by default.

As suggested I set the address to 23 (the default instrument address) using the ++addr command. On sending a command, the logic analyzer was now showing some activity and I briefly saw the instrument indicate 'LISTEN' on the display, which seemed to confirm that it was indeed now receiving the data being sent to it. However it still did not seem to be obeying any commands that I was sending. I tried ++auto and sending 'END ALWAYS', as well as the previous OUTPUT 723;"D2HELLO" but to no avail.

However, at this point, the SRQ and REN lines were still not connected to GND. I had purposely left them n/c as I was contemplating connecting them to channels on the Arduino. Emanuel Girlando's documentation does say that they should be connected to GND and this was also pointed out by JXL. Since they evidently should not be left floating, I decided to complete what I was planning and connected GPIB10 and GPIB17 to channels 2 and 3 of the Arduino board. I then modified the code to add a #define for them and set them LOW. This way I could experiment with them later and would be ready (channel mapping notwithstanding) for any future code update that may implement these features. After compiling and uploading the code I tested it again and this time interface worked! 

So I can confirm that the problem was twofold: the GPIB device address needed to be set to 23 using ++addr and the SRQ and REN lines should not have been left floating.

Hopefully I can now start experimenting with the instruments features. I will have to make a donation to Emanuel for making the code available.

[TheSteve]

It doesn't appear anything much has changed inside the latest Prologix - still just a FTDI USB to serial and an Atmel Mega644PA. There are no parts on the bottom.

[bitseeker]

Interesting. Margins must be pretty good on those.

[mmagin]

Got me curious and I took apart my Prologix Ethernet.  Not a whole lot more.  But I suppose it's the software development and compatibility testing that's being paid for, so I'm not complaining.

[amspire]

Got me curious and I took apart my Prologix Ethernet.  Not a whole lot more.  But I suppose it's the software development and compatibility testing that's being paid for, so I'm not complaining.

It means it is probably slow, and doesn't meet the IEEE488.1 specs for current, but who needs speed, and who needs 15 devices on a single bus?

It is affordable and it works great. Reading the spec is a nightmare, so it is great they have done such a great job at being as compatible as possible.

[lmester]

Here is another option if you want to build your own USB to GPIB adapter.

http://www.dalton.ax/gpib/

It uses a Microchip PIC18F2550. I work with Microchip PIC's and have a programmer for them. If you don't have a PIC programmer, It'll add at least another $30 to the build cost. This is not a good choice unless you have a PIC programmer.

This adapter uses the Prologix command set. It appears as a serial port on your computer.

It does not use proper GPIB transceiver chips. It will probably fail if you have a lot of instruments connected. Iv'e used it with three instruments on the bus and initially had no problems. I later had intermittent data corruption from my HP3478A multimeter. I assumed that the problem was from my cheapo home built GPIB adapter. I coughed up the bucks for a real Prologix adapter. That was a troubleshooting fail After installing the Prologix adapter, I still had the same problem with the 3478A. With more testing, I found that the problem was in the meter. The SN75160B GPIB transceiver was failing. Also, After I popped open my Prologix adapter, I saw that it also does not use GPIB transceiver chips. For what the Prologix adapter costs, I was expecting it to properly support the GPIB standard:)

Since I now have a Prologix adapter, I could compare the Dalton Prologix clone with the real thing. I don't see any significant difference in transfer speed.

The Dalton clone is not 100% compatible with the Prologix adapter. It does not assert the RTS serial control line. This causes problems with the KE5FX ezgpib software.

Also, if you have several instruments, the big cost of GPIB is for the cables and connectors. I was lucky and had a cable to get me started. Anyone remember the Commodore PET computer? It used GPIB to connect to It's  peripherals. I had a cable that was used to connect to a PET disk drive. That cable was in poor shape. Insulation was cracking and brittle. It did allow me to get a GPIB interface up and running in one weekend:) I really needed some new cables. I've now had the painful experience of buying more of these expensive cables.

Finally, GPIB (IEEE-488, HPIB) is amazing. It was created in the 1960's. It's only recently been replaced with USB and Ethernet. A  long life for a bus protocol!

Attached are two pictures. One of my quick & messy perf board wired Dalton GPIB adapter and another of my Prologix adapter with three GPIB cables connected.

[amspire]

Also, After I popped open my Prologix adapter, I saw that it also does not use GPIB transceiver chips. For what the Prologix adapter costs, I was expecting it to properly support the GPIB standard:)

I think from memory, Prologix say they support the IEEE488 standard. They do not say they comply with the standard,

Thanks for this link. I will take a look. Looks like a fairly full featured attempt. They have tried to push the speed (20uS/byte)  and that might be at the expense of bus setting time. They have added resistors, but not the normal IEEE488 terminating resistors, but 10K pullup and 100 ohm series. The series resistor means you definitely cannot drive more then a few devices - probably 2 maximum. I would probably add the standard resistors.

[WaveyDipole]

I saw at least one Arduino design where 100ohm resistors were added in series with all lines although most seem to omit them. There didn't seem to be any pull-up resistors though. Would it be sensible for me to add these resistors to my project?

[amspire]

I saw at least one Arduino design where 100ohm resistors were added in series with all lines although most seem to omit them. There didn't seem to be any pull-up resistors though. Would it be sensible for me to add these resistors to my project?

I am not sure why they are there. Could be to limit current on spikes above 5.5V or below -5.5V, of if they are using active pullups, it may be to limit current if another chip is pulling down. Could also be to limit the current in the case it is powered down.

If someone has the Elektor article, it would be interesting to know.

Here is the cost. If one of your pins is pulling low, the maximum current from one device is 1.6ma - 0.16V across 100 ohms. The maximum voltage you can have for a low signal is 0.5v - so that means you can only drive 3 devices. Probably 2 is safer. If you are happy with a limit of 2 attached devices, then adding the 100 ohms will probably make your interface much more immune to damage.

Instead of the 10K pullup, I would recommend using the 3K pullup and 6K2 Pulldown resistors mentioned in the IEEE488. If your GPIB box is at the end of a cable, having the correct termination may reduce ringing. Also, if you make the outputs behave in Open Collector mode (Set the output LOW and toggle between Input and Output for High and Low), the resistors will provide pullup to the correct voltage for the specification.

The other side of the argument is that it looks like Prologix don't bother with any resistors at all. Perhaps Elector was being more cautious then they needed to be.

[macboy]

One thing the PIC18F2550 based interface has going for it is that this chip has enough TTL inputs for the all data and control lines. A true 2.0 V high input threshold definitely boosts the compatibility. Those PICs also have quite good drive strength on the outputs.

[bitseeker]

If your GPIB box is at the end of a cable, having the correct termination may reduce ringing.

Is it better to have the controller in the middle of the bus, whether it's a real (HP, NI, etc.) GPIB interface or not?

I'll be rearranging most of my instruments in the near future, so it'd be good to know what a preferred arrangement, if any, would be.

[amspire]

It shouldn't matter. The spec allows for 14 devices + the controller and a maximum of 20Meters of cable.

There is a maximum segment length too - forget what it is.

Basically, if you have a fully compliant gpib controller, then as long as you meet the above, it works reliably.

For the Prologix, I would probaby plug it directly at one of the instruments, and stick to 9 attached devices or less and 10meters of cable.

For the Elector-based design, 3 absolute maximum devices.

The thing that would mess this up is if you had many non-compliants devices (like the Prologix). As long as it is just the controller, that is OK.

[bitseeker]

Thanks, amspire.

The following ICS document, on page 6 in the section "GPIB Bus Cables", recommends a maximum segment length of 2 meters for best transfer rates.

https://www.icselect.com/pdfs/ab48_11.pdf

[amspire]

Yes, the way it works is a cable segment can have a maximum capacitance of 100pF on each wire. The proper termination on a device is 2000 ohms (3K + 6K2). That gives a time constant of 200nS. If you have 20 meters of cable, that can be 1000pF per wire, but you have at least 10 terminations so you get 200 ohms. The time constant is still 200nS.

You can still get excellent speed with Open Collector outputs, but if you need to push the speed to the limits, you will need active pullup and pulldown

When a controller is pulling a line low, it can send the line low in less then 100nS which happens to match the minimum time mentioned in the IEEE488 spec.

I haven't seen the high speed GPIB spec developed by NI.

[lmester]

I saw at least one Arduino design where 100ohm resistors were added in series with all lines although most seem to omit them. There didn't seem to be any pull-up resistors though. Would it be sensible for me to add these resistors to my project?

I am not sure why they are there. Could be to limit current on spikes above 5.5V or below -5.5V, of if they are using active pullups, it may be to limit current if another chip is pulling down. Could also be to limit the current in the case it is powered down.

If someone has the Elektor article, it would be interesting to know.

I have the article. It's in Elector July-August 2012. Unfortunately, there is little detail on the operation of the circuit. They do mention that the pic pins are being used as open collector. Switching the pins between input and output.

[texaspyro]

Hope this doesn't result in a duplicate post...  the last time I tried it didn't make it through...

Here is some GPIB C code that I wrote a while ago.  It works on AVR chips (tested on Mega128 and 2561).  Emulates a Prologix GPIB-Serial converter.   Tested with GPIBKIT.   Released under the MIT license.

Note that the attached code is not complete (it uses LCD/touchscreen/serial I/O routines and some header files that are not included),   but should be fairly easy to modify for other systems.  You can find the missing code here:

https://github.com/ron-grant/Mega-Donkey

The file also has code for emulating another GPIB interface...  it should be nuked from orbit.

The serial I/O routines are interrupt driven and fully bufferd.

[amspire]

Hope this doesn't result in a duplicate post...  the last time I tried it didn't make it through...

Here is some GPIB C code that I wrote a while ago.  It works on AVR chips (tested on Mega128 and 2561).  Emulates a Prologix GPIB-Serial converter.   Tested with GPIBKIT.   Released under the MIT license.

Note that the attached code is not complete (it uses LCD/touchscreen/serial I/O routines and some header files that are not included),   but should be fairly easy to modify for other systems.  You can find the missing code here:

https://github.com/mega-donkey/Mega-Donkey

The file also has code for emulating another GPIB interface...  it should be nuked from orbit.

The serial I/O routines are interrupt driven and fully bufferd.

Looks interesting and it is MIT license! 

The way you have written the code, it shouldn't be too hard to modify for a non Mega-Donkey board. I will try it out when I get some time.

I have just recently got myself my first 3D printer kit, and I want to get back to building a GPIB device, now I can make good enclosures. My ideal would probably have both USB and WiFi ethernet options and be very cheap (under $30 would be good). Cheap means I can easily make as many as I want.

Richard

[texaspyro]

It should be fairly easy to adapt... mainly figuring out what code is not needed/used.  There are some test/demo/debug output routines left in there from the last time I was using it.  I tend to edit it for whatever evil project I am doing at the time.

The serial routines are basically output character (to a buffer that is sent to the uarts via interrupts),  check for serial char available, and get serial char from the buffer.    printf()'s go to the screen for status and debugging.  There are a couple of calls to some touchscreen routines (like wait for touch).

There are some comments talking about DEVICE mode not being implemented.  I seem to remember that I did get it to work... at least for what I was doing at the time.

[amspire]

The serial routines are basically output character (to a buffer that is sent to the uarts via interrupts),  check for serial char available, and get serial char from the buffer.    printf()'s go to the screen for status and debugging.  There are a couple of calls to some touchscreen routines (like wait for touch).

I do not plan on having a LCD display or buttons, so I would either eliminate the LCD options or move them to custom Prologix-type commands.

There are some comments talking about DEVICE mode not being implemented.  I seem to remember that I did get it to work... at least for what I was doing at the time.

I saw that. Usually the home-brewed GPIB code does not include the DEVICE mode. Did you try and make the code conform to any particular version of the GPIB standards, or did you just try and make it behave like the Prologix?

[WastelandTek]

great thread, I have 3 instruments with GPIB and my OCD hates unused features/empty ports

there was an extra arduino around here somewhere...unfortunately, I scrapped a bunch  of GPIB cables back in the day before I knew what they were...I was like "WTF is this? some obsolete soviet printer plug??"

[texaspyro]

I saw that. Usually the home-brewed GPIB code does not include the DEVICE mode. Did you try and make the code conform to any particular version of the GPIB standards, or did you just try and make it behave like the Prologix?

Well,  neither.    I needed device mode for something ('twas a long time ago) and put it in.   It worked for what I needed it to do.   

[maxwell3e10]

I thought I would revive this thread. Has anyone seen this implementation of GPIB to USB on Atmega AVR 32U4 chip?
http://www.kingswood-consulting.co.uk/gpib/

It includes code under GPL license and the proto boards cost $2 shipped on ebay. I don't have experience in microprocessor programming, so it wouldn't be time effective for me to play with it. But I wonder if someone here can easily make a program that runs on Windows to upload the code and make it compatible with EZGPIB? This may finally solve the problem of getting a cheap and relatively painless GPIB adapter.

[bitseeker]

Thanks, maxwell. I hadn't seen a 32u4 implementation before, just the 328p ones. The blog post says it was inspired by the ProLogix controller. I wonder if it's similar enough that EZGPIB would work with it as-is.

[MarkMLl]

The code runs fine on my Deumilanove board, and as mentioned before, I just cut a GPIB cable in half for the connection. I secured the cable with a tie through one of the mounting holes and tacked the tie to the cable in a few spots with the soldering iron to stop the cable from rotating. The board I used was a cheap Arduino clone, but with with real FTDI chip. Any working RS232 interface chip should work.

If I could make an extremely belated comment here: one of the useful things about having a "genuine" (or at least functionally complete) FTDI chip in a project is that you can write an 8-character serial number into it. So in the current case, you could write "IEEE-488" as a serial number, and then- at least on Linux- walk the /sys filesystem to find where it's plugged in.

MarkMLl