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 (http://www.edn.com/design/test-and-measurement/4318969/Build-a-USB-based-GPIB-controller)
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 (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 (https://egirland.blogspot.dk/2014/03/arduino-uno-as-usb-to-gpib-controller.html)
Edit: Damm beaten by Plesa :box:
/Bingo
LQ Electronics sells a cheap one. Not a lot more than you would pay for the parts for a home brew version.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.
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 (http://www.edn.com/design/test-and-measurement/4318969/Build-a-USB-based-GPIB-controller)
| 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 |
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. |O
I see you are not in the states... this may not be for you with customs and taxes?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.
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.
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.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.
Failing that, you could post about what you did to improve it. We're keen on reading about it.
NoDerivatives — If you remix, transform, or build upon the material, you may not distribute the modified material.
Here is the words from the CC nonderivative license:QuoteNoDerivatives — 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?
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.
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.Here is the words from the CC nonderivative license:QuoteNoDerivatives — 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.
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 $.02Thank you for that SQL code - I will take a look.
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.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.
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).
"do what you like, but don't blame me"
ARDUINO GPIB firmware by E. Girlando Version 6.1OUTPUT 723;"D2Hello"> gpibWrite: timeout waiting NDAC
set_comm_cntx: gpib write failed @1
gpibTalk: set_comm-cntx failed.
>
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?
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,
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 your GPIB box is at the end of a cable, having the correct termination may reduce ringing.
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.
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.
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?
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?
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.