-
I have been wanting to drive some GPIB meters, function generators, etc for ages, but I don't want to pay for the excellent Prologic converters. One converter costs more that I paid for any of my GPIB instruments (except for the HP33120A), and for the money, you still only get one converter. I want something cheap enough so that if you want to run instruments in different locations, you can afford to have as many converters as you need.
Also I want something that can be run from any computer, and I never want the phrase "Visa Drivers" mentioned even in jest.
Should be able to put together a GPIB Server to USB for well under $20 providing you have an old GPIB cable you can murder. The Ethernet version will add a big $24 to the cost.
Actually I want two converters - a GPIB to USB and a GPIB to Ethernet. I really think Ethernet is the way to go. I have a pair of Ethernet over the Power line transceivers, so I would be able to have the instruments running anywhere I have a powerpoint, and control it from any other computer on my home network.
It is quite easy using an Arduino. I will do my initial development on an Arduino Duemilanove. Once it is running, I will build a single chip version on a standard $2 Arduino RBBB board using the very cheap Nokkia CA-42 clone USB to serial cable to add the USB.
The code will be based on some code I found on this Japanese site:
http://bananawani-mc.blogspot.com/2010/09/arduinogpib.html
With no boards to layout, and most of the code written, it hopefully will be quick to get something going.
The goal is to make something good enough to be able to send a string command to an instrument, and to read back a string response. That is enough to be able to set up a function generator or DMM, and to be able to automate readings from a DMM. Any scripting language that can talk to a RS232 port or an Ethernet port will be all that is needed, so I could even run a macro from a spreadsheet and have the spreadsheet dump process the data as it comes in. LibreOffice (OpenOffce) gives a choice of Basic, Javascript, Python or Java Beanshell for macro languages. Alternatively a simple standalone script can dump readings into a CSV file.
Initially, I will not worry about the service request commands, a number of other standard GPIB commands, or proper ieee488 terminations (all the instruments have the terminations in already - that is good enough). I am not looking for anything fast. If you need speed, then you will want one of the the Prologic converters, or one of the $130 Agilent convert clones.
Richard -
I believe the Prologix developer spent quite a lot of time getting his adapter to work with various kinds of instruments, your work may be simpler if you just want to support a limited set of instruments. Not supporting standard APIs like VISA means you won't be able to use any off the shelf software. Probably not a big deal for a piece of 1980s equipment with only software for the HP85, though it might be nice to be able to use the Agilent Intuilink software for the 33120A.
But good luck on your project, it would be good to have a cheap option (outside that useless Softmark thing) for hobbyists. There are some GPIB implementations on AVR out there, like this and this. No idea how functional they are. -
I believe the Prologix developer spent quite a lot of time getting his adapter to work with various kinds of instruments, your work may be simpler if you just want to support a limited set of instruments. Not supporting standard APIs like VISA means you won't be able to use any off the shelf software. Probably not a big deal for a piece of 1980s equipment with only software for the HP85, though it might be nice to be able to use the Agilent Intuilink software for the 33120A.
Most instruments have pretty easy commands. So it is only something like the 33120A arbitrary waveform that would need the better interface. I will get it going first and worry about that later.
I am extremely happy if I do not need API's and Drivers. I just want to send a command and get a reply back.QuoteBut good luck on your project, it would be good to have a cheap option (outside that useless Softmark thing) for hobbyists.
I would have purchased one of the Softmark interfaces if they just made it more open. I do not want to have to use their rather lame software.QuoteThere are some GPIB implementations on AVR out there, like this and this. No idea how functional they are.
I am aware of thpse two projects.
The Ethernut requires the expensive and hard to get NI GPIB chip - don't want that.
The University of Ljubljana is an impressive project, but it is not really open. You can request the details of the old design, but if you want the latest version, you have to buy it at a big price. Also, it is not Ethernet.
To me Visa drivers and Labview are two of the worse things to have happened to instrumentation. It was done with the best intentions, but the results are a mess. The Visa drivers tend to be the most over-bloated problematic and poorly designed pieces of software around, and until there is an Opensource Labview equivalent, I do not want to touch it. I am more then happy to replace 500MBytes+ of dodgy software which will only run on specific platforms with a 20 byte text string that I work out from the manual that can be sent from anything. (If you don't believe me, just try and install the Agilent and NI Visa drivers on the same PC). With a telnet-compatible driverless Ethernet GPIB converter, I could even control the instruments from my mobile phone! I can get Python and Lua sricpting for my phone so the phone could grab the data and make a CVS. That is real power.
Richard. -
I am extremely happy if I do not need API's and Drivers. I just want to send a command and get a reply back.
I would copy the Prologix command set if you don't implement something like GPIB32. This should be a protocol with a low overhead and at least some software support (like the software by John Miles).I would have purchased one of the Softmark interfaces if they just made it more open. I do not want to have to use their rather lame software.
Very limited, closed and undocumented as I understand it. Anyone who bought it has considered it a waste of money as far as I know.To me Visa drivers and Labview are two of the worse things to have happened to instrumentation. It was done with the best intentions, but the results are a mess. The Visa drivers tend to be the most over-bloated problematic and poorly designed pieces of software around, and until there is an Opensource Labview equivalent, I do not want to touch it. I am more then happy to replace 500MBytes+ of dodgy software which will only run on specific platforms with a 20 byte text string that I work out from the manual that can be sent from anything. (If you don't believe me, just try and install the Agilent and NI Visa drivers on the same PC). With a telnet-compatible driverless Ethernet GPIB converter, I could even control the instruments from my mobile phone! I can get Python and Lua sricpting for my phone so the phone could grab the data and make a CVS. That is real power.
No argument here, although instrument drivers are sometimes handy for more complex devices, the amount of overhead is enormous (Labview alone is more than 500MB). I believe there are VISA bindings for Python, but that still requires the NI-488.2 drivers or Agilent IO suite.
Debugging GPIB issues can be interesting, even with known-good hardware. Instruments will often just ignore commands if they don't understand them, or return an error a minute and many commands later. The more recent IEEE 488.2/SCPI equipment tends to be better than the old stuff in this regard. -
I would have purchased one of the Softmark interfaces if they just made it more open. I do not want to have to use their rather lame software.
I bought one and returned it within a few days. From what I could gather, it didn't completely conform to the GPIB standard and thus didn't work with every device. In particular, it didn't work with anything I own. The software was also terrible. I bought a Prologix one, which works great, but they are considerably more expensive than I would have hoped.
I did think about creating my own, too. A CPLD and USB-serial device would give you a lot of flexibility. -
i never do the GPIB, but the way i see, command to specific device is not that important, its a matter of getting it from the device documentation. the most important thing is the converter, ie to make pin compatible from USB to GPIB, translation will be done in mcu (arduino) should not be hard to do once the GPIB protocol and pin arrangement is understood (me not yet).
but any devices/chip that are going to be connected to an OS will need a driver and API/SDK. even arduino are going to need FTDI API dll (or that not so my flavored serial port command in the IDE), i only never heard a device without a driver/api, except serial and parallel port (whose drivers are actually embedded in the OS).Quoteand I never want the phrase "Visa Drivers" mentioned even in jest ... I am extremely happy if I do not need API's and Drivers
and the software/GUI is another story, thats a higher level of abstraction, others have made their opinion on that. in my word, you got to diy if you dont like off-d-shelf
serial command in arduino IDE is generic one (you can do anything with it) but with slow and unautomated manned (manual typing the command) operation.
my 2cnts.
-
i never do the GPIB, but the way i see, command to specific device is not that important, its a matter of getting it from the device documentation. the most important thing is the converter, ie to make pin compatible from USB to GPIB, translation will be done in mcu (arduino) should not be hard to do once the GPIB protocol and pin arrangement is understood (me not yet).
I the Nokia cable has a Prolific USB to serial converter from memory. I seem to remember that Windows 7 recognized it without loading any driver, but perhaps it because I had previously installed some software that included the Prolific driver. And the driver for the FTDI chip on the Arduino board probably is somehow installed by the Arduino software. I will do some tests on a pristine Windows XP system later.
but any devices/chip that are going to be connected to an OS will need a driver and API/SDK. even arduino are going to need FTDI API dll (or that not so my flavored serial port command in the IDE), i only never heard a device without a driver/api, except serial and parallel port (whose drivers are actually embedded in the OS).
But USB to GPIB converters in general are bad news - the port changes every time you plug it into a different USB connector on the PC. That is one of the many reasons I think that the GPIB to Ethernet converter will be far more useful. Definitely no drivers needed for accessing an Ethernet port. I will start with the USB design, and when my Ethernet shield comes in, it will be a simple change to change the USB commands to Ethernet commands.QuoteQuoteand I never want the phrase "Visa Drivers" mentioned even in jest ... I am extremely happy if I do not need API's and Drivers
and the software/GUI is another story, thats a higher level of abstraction, others have made their opinion on that. in my word, you got to diy if you dont like off-d-shelf serial command in arduino IDE is generic one (you can do anything with it) but with slow and unautomated manned (manual typing the command) operation.
I want both the manual command option in a terminal window, and also the ability to embed the commands in scripts which will probably run as fast as I need. Both should be straightforward.
Anyway, just about to connect up my Arduino to a GPIB cable and get to work. i will find out the problems pretty soon.
Richard -
Quote
I seem to remember that Windows 7 recognized it without loading any driver
Microsoft excels at that, with newer OS, they try to load any drivers on earth into their OS. about the arduino (ftdi), try to connect it to a fresh installed windows and it will ask the ftdi driver... that famous "New Device Found" thing.QuoteI want both the manual command option in a terminal window, and also the ability to embed the commands in scripts which will probably run as fast as I need. Both should be straightforward.
command line can be powerful, but when it comes to repetitive and high data rate task, then... having worked with ftdi and its API, simple scripting is not that "straightforward", you need to handle things like latency and synchronization. when you get deep into it, you'll see the nasty and messy thing about it, thats what high level abstraction is needed for... good luck!
-
To me Visa drivers and Labview are two of the worse things to have happened to instrumentation. It was done with the best intentions, but the results are a mess. The Visa drivers tend to be the most over-bloated problematic and poorly designed pieces of software around, and until there is
I don't like labview, or most vendor instrument "drivers", but I quite like VISA, bloated as it is. It has some issues -- some of which are problems with VISA and some are problems with vendor implementations, but in the end it basically delivers. I can write an application in python, matlab, labview, or most anything else and it can transparently talk to devices over GPIB, RS232, USB, ethernet, or devices connected to a remote host by any of those protocols simply by changing the device string. A GPIB adapter that isn't VISA compatible would be a deal breaker for me.
-
I don't like labview, or most vendor instrument "drivers", but I quite like VISA, bloated as it is. It has some issues -- some of which are problems with VISA and some are problems with vendor implementations, but in the end it basically delivers. I can write an application in python, matlab, labview, or most anything else and it can transparently talk to devices over GPIB, RS232, USB, ethernet, or devices connected to a remote host by any of those protocols simply by changing the device string. A GPIB adapter that isn't VISA compatible would be a deal breaker for me.
In terms of a professional solution, I think you are right. At the end of the day, Visa works and there is not really an alternative.
For home use, most of the time you are fine using instruments from the front panel. Every now and then, you need to do something like measure a batch of resistors, and getting the readings directly from the meter to a spreadsheet is better then manually typing each measured value. In this case, I think sending a simple command to tell the meter to take a reading, and receiving the reading is simpler then setting up Visa, learning how to use it. If you were using it regularly, I am sure it becomes easy, but for a once off job, I am not sure it is the best solution.
That is the niche I am targeting because right now, there is not really anything that is very cheap and allows you to simply talk to your GPIB instrument. If you want to get serious, then you pay the $130 to $230 for GPIB converters with Visa drivers.
Just as an example, I have a project for which I need to take a batch of readings on a DMM. I can store up to 1000 readings on the DMM, but I then need to get them to a computer, I need to send a single line command string, and the meter will send back the measurements in comma delimiter ASCII. So I only need just that one GPIB function right now. It seems to me that my GPIB (if I can get it to work) will be perfect for this task.
If I wanted to totally control the meter remotely, then my converter would be painful, because to cope with all the complex meter options and the unfriendly commands, I would end up writing the equivalent of a Visa driver. May as well get the commercial converter.
Richard -
IMO, for the $140 or so for the Prologix device, it can't be beat. The FTDI chip set is the only way to fly. I use the FTDI drivers for that with little trouble. I also use the Agilent I/O suite at work, but everything there is direct USB now, so I don't need a GPIB interface. I once tried to do GPIB on the cheap with a digital port card, but it's harder than it looks, plus I was trying to interface to ancient HP stuff at the very beginning of GPIB. You also need open collectors for most lines. I'd run, not walk, for the Prologix device!
-
You also need open collectors for most lines.
Driver ICs worth 4 to 5 Euro in total fix this. One 75160, one 75161. Both e.g. available from your unfriendly Farnell office near you.
GPIB is a really magic interface. In the good old days of home computers you could buy GPIB interfaces for your home computer. They consisted of some driver ICs, a little bit of 74xxx logic, an I/O interface IC, and a 2k ROM with the protocol implementation and BASIC extension. The home computer's meager 8 bit CPU was executing the protocol code from the ROM, and people could talk to their GPIB devices with BASIC.
Then some magic happened. GPIB became professional, became really expensive and suddenly requires interface gear more expensive then several home computers in the good old days. -
Then some magic happened. GPIB became professional, became really expensive and suddenly requires interface gear more expensive then several home computers in the good old days.
One of the really annoying things is you have to pay a fortune to get a hold of the standard. For hobbyists, you have to make do with discovering information out of the odd tutorial or waveforms in instrument manuals. It was much better when it was HPIB as HP actually wanted people to use it.
Once it was in the hands of the IEEE, they seemed quite happy to kill it for hobbyists. Stupid!
I started of using GPIB with the fantastic HP 9825A programmable calculators. They used a simple Basic language, but were designed with 3 I/O slots that could take a GPIB controller, a RS232 controller or a digital IO adapter.
The thing is it was just so easy to control instruments. Just turn it on and go. Admittedly back then, the instruments had fairly low power micro's so the GPIB commands tended to be fairly simple.
It certainly was a great interface for controlling instrumentation.
Richard -
If they had a micro at all. Some of the early GPIB devices were built from just discrete logic.
-
If they had a micro at all. Some of the early GPIB devices were built from just discrete logic.
That wouldn't surprise me. I have a programmable decade resistance box from Time Electronics in the UK, and it has a GPIB interface and a micro. The whole code in the micro for reading the front panel thumbwheels, controlling the six decade resistance cards and implementing GPIB is just a few hundred bytes I think it responds to about 3 single letter commands, and if you send it a number like '1234", it sets the resistance to 1234 ohms. I am sure you could implement something similar all in hardware. -
I thought this was going to be a really quick project - at least to the stage I could test it.
All I had to do was write some simple code to allow the Arduino to send strings over the RS232 via the FT232 chip and then add it to the GPIB code that I already have. Should be easy? A day later and I am still nowhere.
I think sending strings from the Arduino is fairly reliable, but the inbuilt serial code to receive looks like it is flaky. I am not sure if it is something about Windows 7 64 bit and the FTDI drivers, using Putty as a terminal or what, but the Arduino freezes all the time. Closing the RS232 connection on the PC unfreezes it, so it must be something to do with the FTDI chip or its drivers but that doesn't quite make sense - the Arduino supposedly has no flow control, and it only tries to read data when something is in the read buffer. It should just send data whatever the state of the FTDI chip, so it should just never stall.
Other then the Tx and Rx connections from the FT232RL and the micro, the only other connections to the are the RTS and the DTR to the reset pin. Could it be the reset pin? When I connect the terminal program to the serial port, the FT232RL resets the Arduino on the Duemilanove board! Ouch!
For some reason, the "space" character in particular causes a problem.
The arduino is meant to use a 127 character buffer, but maybe that is for sending only. It looks like I may have to write my own code to send and receive the rs232 on the PC and to implement my own handshaking scheme to avoid any overrun. Perhaps I have to add my own checksum to confirm that data was sent reliably. It has to be possible as the IDE uploads the code to the Arduino without a problem, but it is disappointing to see that the standard Serial library is so bad.
I have the oscilloscope out already to try and see what is happening and I will soon probably have to get the logic analyzer - just for the most basic possible RS232 communication using standard Arduino function calls!
Crazy!
If someone has managed reliable two way communication with an Arduino and has some advice, let me know.
Richard. -
Could it be the reset pin? When I connect the terminal program to the serial port, the FT232RL resets the Arduino on the Duemilanove board! Ouch!
Hello Richard,
i remember another thread where it was mentioned that indeed a handshake signal is used to reset the Arduino. I think you are now facing the downside of this simple approach.
Can you configure your terminal programm not to touch the handshake lines? Maybe try another terminal programm. I like teraterm and hterm (http://www.der-hammer.info/terminal/). Don't know if hterm is available in english).
Best regards, Martin
-
Martin,
Thanks a lot. I was looking for a minimalistic terminal package and HTERM works like a dream. It looks like the Arduino behaves well.
I should be able to complete my serial routines now and start testing.
Richard -
A day later and I am still nowhere.
you are in very good hand
its normal i think the arduino resetted everytime plugged into the PC and when being programmed (bootloader need to be aware of something 1st during the time). good luck with your debugging. i'm going to try out Win32 Comm API next to comm with the arduino (due to the new Uno USB Chip)
edit: if you need some pointer, you may check my ftdi (serial comm) setting "embedded" in here Whats UART->USB Chip like FTDI FT232RL is Thinking in Term of Mbps Speed? (i work with byte, not ascii and hence the setting by try and error) and you need sometime after startup (arduino reset) to make serial comm to be responsive, iirc sending garbage data first (in a packet), the second data will get the respond, btw that was a dirty hack, you may come up with better method.
-
Richard,
How did you go with this project? -
If people are still interested: this is about as low-cost as you'll get.
Gee Whiz, a GPIB-to USB Converter
$50 interface circuit brings 80s/90s edebris to life
Published in Elektor Magazine, issue 427, July/August 2012. Uses a PIC18F2550 @ 20MHz with on-chip USB interface.
http://www.elektor.com/magazines/2012/july-047-august/gee-whiz-a-gpib-to-usb-converter.2188340.lynkx -
I know Im bringing up an old thread, but last week i designed and built my Own GPIB-USB controller. Its really not that difficult hardware. I used a PIC18f4550 with built in USB. This weekend i wrote the software and used the prologix command set as a way to make it compatible with some software. I have tested it with my HP 54502A and my Solartron 7150 and they both function well with it. I still have a few features i need to add to make it full prologix compatible ( its not yet recognized by the Prologix configurator). Not sure if i should get some boards for this made up and release it to the wild.
Overall i think not a bad weekends work.
Bread boarding it.
Built onto Vero Board
Simple Test With scope. There are More commands than listed with in the screen shot, just haven't got round to updating the help command yet.
-
The good old hp9825 & hpl, I pushed the expanded version to it's limits doing real time data collection and processing. At the last, was having to rewrite sections of program just to get the space for new code. The 9826 was a nice dream that ended up on my desk before the PC AT came out, That dream had a memory card for every slot and an hpib harddrive.
any way
you probably know of the TMS9914a chip an someone else mentioned the gpib driver chips
A quick google says the arduino does not do serial xon xoff so receive buffer overrun could be a problem
C -
USBQuote
But USB to GPIB converters in general are bad news - the port changes every time you plug it into a different USB connector on the PC
I have read that this is caused by lack of a serial number on the USB device.
With out a serial number, windows thinks you have two different usb devices.
C -
I have been wanting to drive some GPIB meters, function generators, etc for ages, but I don't want to pay for the excellent Prologic converters. One converter costs more that I paid for any of my GPIB instruments (except for the HP33120A), and for the money, you still only get one converter. I want something cheap enough so that if you want to run instruments in different locations, you can afford to have as many converters as you need.
That pretty much sums up my current situation as well. I do have a working parallel port DIY solution, but I cobbled that together ages ago. I just checked my bit-banged code and it is 2002 vintage.
Also I want something that can be run from any computer, and I never want the phrase "Visa Drivers" mentioned even in jest.
Should be able to put together a GPIB Server to USB for well under $20 providing you have an old GPIB cable you can murder. The Ethernet version will add a big $24 to the cost.
Actually I want two converters - a GPIB to USB and a GPIB to Ethernet. I really think Ethernet is the way to go. I have a pair of Ethernet over the Power line transceivers, so I would be able to have the instruments running anywhere I have a powerpoint, and control it from any other computer on my home network.
Since one of those days my trusty old parport machine is going to go *urgle* AND since I just had a new addition to the GPIB collection AND since there will probably be another addition in the foreseable future maybe now is the time to DIY a somewhat nicer solution. Oh and for the free_electron's amongst us, that 2002 DIY solution does service SRQ's and does binary transfers. I even used perl, and for the new solution I will use python for my scripting. So there.
Just like amspire I would like a cheap solution so I can have several GPIB adapters in various locations. For my use case the obvious solution is ethernet. You cannot leach power from the GPIB port in a nice way that meets spec (AFAIK so please correct me if I'm wrong), so you will have to provide external power. Since for some strange reason 12 Volt wallwarts multiply like rabbits around here I'll use that for power. Which neatly opens up the other option of using (PoE) power over ethernet as well. On ebay you can get cheapo PoE adapters, so that way I have 12 volt injected into the cable near my switch. Plug the other end into the GPIB adapter and we have power. Another nice thing about the ethernet solution is ... no driver issues. So this should work for anyone on any OS.
In some of the other threads I noticed the comments about using proper drivers. As far as I can tell that mostly boils down to 1) being able to sink enough current and 2) not loading the bus when in off state. I think I'll just use SN75160B + SN75161B since those are affordable enough. Not exactly cheap for silly 8-bit bus transceivers but oh well, not going to flush lots of time "optimizing" the cost there.
For mcu I will probably grab an msp430 or stm32, a bit depending on how fast I want that ethernet to be. I did think about using an fpga but implementing the network side of it becomes a pain real fast. I've done some simple UDP + ARP stuff in the past with a simple fsm, but I think this will have to be tcp. And well yeah, but no. Not going to do that in verilog. Hopefully I can grab some existing C/C++ code from another mcu based GPIB project somewhere as starting point. If not I'll use my super old code and polish that a bit. Any hints in that regard? Any reasonable code bases out there? If only to just read it for some inspiration.QuoteThe goal is to make something good enough to be able to send a string command to an instrument, and to read back a string response. That is enough to be able to set up a function generator or DMM, and to be able to automate readings from a DMM. Any scripting language that can talk to a RS232 port or an Ethernet port will be all that is needed, so I could even run a macro from a spreadsheet and have the spreadsheet dump process the data as it comes in. LibreOffice (OpenOffce) gives a choice of Basic, Javascript, Python or Java Beanshell for macro languages. Alternatively a simple standalone script can dump readings into a CSV file.
What's the status of this? Any lessons learned, things you would do differently now?