GPIB interface (IEEE488)

[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