Get a better experience by installing our free app!
Not now
Install
Get a better experience by installing our web app!
Hide
How to do it?
In Safari, tap on the menu bar. Scroll down the list of options, then tap Add to Home Screen.(If you don’t see Add to Home Screen, you can add it. Scroll down to the bottom of the list, tap Edit Actions, then tap Add to Home Screen.)
Over the years I have made use of the IEE488 bus on test equipment in my job. But I always used "out of the box" software from the equipment manufacturer to control things. Now I have an IEE488 equipped instrument from the 80s that I would like to control from my laptop. I see some relatively inexpensive USB to IEE488 adapters on eBay but I am hesitant to spend any money until I know that I can do what I need to do. The problem is that manuals for this instrument are not readily available and the manufacturer wants 100 dollars for one.
Since I have never programmed an HPIB/IEE488 device directly, I know nothing about how the control is actually accomplished. Does each instrument have a unique vendor-specific set of commands? or does the IEE488 standard specify standard commands? Is there any hope of being able to do things with the instrument without some documentation on the details of the IEE488 interface for the device?
The instrument in question is an Anritsu ML422C Selective level meter. It is functionally very similar to the HP 3586C with many similarities in operation. Even many of the controls have the same names. maybe an HP manual would be useful in figuring out how to do the programming?
Anybody here every write software to talk HPIB or IEE488?
Edit: Yeah I know, it's IEEE488. At least I'm consistent in my error.
Hi Tony, I too would like to connect my PC to an IEEE-488 port.
But, I have not found any relatively inexpensive USB to IEE488 adapters.
What prices are you seeing?
I'm not a major computer geek but yes, all the manuals at least from Tektronix or Hewlett Packard for instruments that are interface bus equipped include a section on the addresses for the bus. Each instrument will obviously have its own set of commands- that is how they are programmed and the manuals explain the commands for each instrument.
Now... finding or writing software is a different story. There is commercial instrument software available with drivers even for a lot of the older instruments. But it's expensive, unless you can find a bargain somewhere. It's not likely something a hobbyist will want to spend the money on. I also would like to know if anyone here has written any instrumentation software?
The one I am talking about is the ProLogix for 149 bucks. Having used National Instruments products which can run over 500 dollars, I called this "relatively" cheap.
I've been doing a little reading and it looks like the standard has basic commands standardized (like power on/off I suppose) but instrument specific commands are not. There was a revision of the standard in 1987 to improve the situation but this is likely after my instrument was made. It looks like you need instrument documentation to make any headway beyond turning it on and off.
I found a web site that has plans to make your own USB to GPIB interface. I think that this is the link:
It strikes me that regardless of whether you buy or build a USB adapter that you still need the intrument-specific command structure, and preferably some sample code. With that in hand you should easily be able to build a user interface, perhaps using something like Visual Basic. I suspect you know that & I'm just preaching to the choir!
Writing IEEE 488 (a.k.a. GPIB - General Purpose Interface Bus) commands is very much like communicating over a serial port. The set up is different, however, as you don't have to set bit rates or anything like that. You may have to set bus addresses depending on how many devices are hanging on the bus. The commands that go to the GPIB controller are usually preceded by something that doesn't show up in GPIB commands. In the case of the Prologix controller, this is ++.
For instance, say you want to communicate to an HP power supply which is set up as device 5 on a GPIB. This is the sequence of commands assuming you're talking to a Prologix board:
++addr 5 ---- Prologix: Set destination address to 5
++auto 0 ---- Prologix: Turn off automatic reads after commands
*idn? ---- Ask device 5 to identify itself
++read eoi ---- Prologix: read until device indicates EOI
VOLT 3.3 ---- HP: Set output voltage to 3.3V
CURR 1.0 ---- HP: Set output current to 1.0A
OUTP ON ---- HP: Turn on output
MEAS:CURR? ---- HP: Measure current being output
++read eoi ---- Prologix: Read response
Note that everything after and including the ---- is a comment and is not part of the command series. Sending that stuff will cause both devices to complain.
Depending on how anxious you are to reinvent the wheel, there are a few of these sorts of projects floating around that could serve as starting points:
And N.I. has a lot of good resources, most centered around their own products, but some are good for educational purposes and useful to help you understand the processes of GPIB:
Interesting information. John thanks for the example code.
One thing to consider if you are thinking of writing your own code is that starting with XP the devices were protected from direct program access. Instead you have to talk to a device like the USB or GPIB via a "device driver". I thought this was a PITA when I moved from Win98 to XP and had trouble getting my project which accessed the Parallel Port to work.
I know VB.NET fairly well and I think it is the best IDE I have ever seen. But, if I were to program a device today, I would seriously consider Linux because it seems to have so much to offer. Not sure if Linux will require a device driver interface like XP.
It is re-inventing the wheel, or trying to work back in time. HP did have GPIB instrument software for their 85/87 computers and the 41C/CV calculators. But we are talking a period of a few years in the mid 1980's. And it really didn't do much by what we would consider useful today. It allowed remote instrument control, and input/output data collection. There was no sort of graphic interface at that time, just lines and numbers.
It would be neat to see a graphic instrument interface using GPIB, but I think it would be something more cool to look at rather than it having a whole lot of usefulness, at least from the hobby standpoint. It would be a ton of work too.
There are some very nice GPIB utilities here written for the ProLogix USB/IEEE488 adapter. There's a HP plotter emulator, a phase noise measurement utility, a waterfall display for a spectrum analyzer, etc.
If you have an instrument with IEEE488 and a "plot" button, the plotter emulator is worth it alone.
MarkPalmer wrote:It is re-inventing the wheel, or trying to work back in time. HP did have GPIB instrument software for their 85/87 computers and the 41C/CV calculators. But we are talking a period of a few years in the mid 1980's. And it really didn't do much by what we would consider useful today. It allowed remote instrument control, and input/output data collection. There was no sort of graphic interface at that time, just lines and numbers.
It would be neat to see a graphic instrument interface using GPIB, but I think it would be something more cool to look at rather than it having a whole lot of usefulness, at least from the hobby standpoint. It would be a ton of work too.
-Mark-
In my case it would be very useful. I use this SLM for longwave beacon monitoring. Some of the best times to be listening for beacons is when I should be sleeping. I currently use other software to either record the audio for later playback through my SpectrumLab software or I use SpectrumLab to make periodic captures of the waterfall display which I can review the next day. The lack of receiver control forces me to park on one frequency for the entire night. This is not too bad but I would like to make sweeps through the longwave band automatically and that requires receiver control. The GPIB would give me what I need. It looks like the control software would be very easy to write for a task as simple as this.
w3jn wrote:There are some very nice GPIB utilities here written for the ProLogix USB/IEEE488 adapter. There's a HP plotter emulator, a phase noise measurement utility, a waterfall display for a spectrum analyzer, etc.
If you have an instrument with IEEE488 and a "plot" button, the plotter emulator is worth it alone.
I am researching the programming in regards to the HP 3586. Chapter 11 of its operator manual (can be downloaded free from Agilent) lists all the programming codes for it, over 3 pages of them. If you get something set up to use the GPIB and can't find the codes for the Anritsu, you might want to try the HP ones. I'm surprised no literature on the ML422C is available for download from Anritsu despite it being in one of their catalogs as recently as 2002. I think the HP 3586's were discontinued in the early 90's.
MarkPalmer wrote:I am researching the programming in regards to the HP 3586. Chapter 11 of its operator manual (can be downloaded free from Agilent) lists all the programming codes for it, over 3 pages of them. If you get something set up to use the GPIB and can't find the codes for the Anritsu, you might want to try the HP ones. I'm surprised no literature on the ML422C is available for download from Anritsu despite it being in one of their catalogs as recently as 2002. I think the HP 3586's were discontinued in the early 90's.
-Mark-
I downloaded the 3586 manuals the other day but I haven't had time to look at them. I have to spend 150 bucks to find out that the 3586 codes won't work and then I have to spend another 100 to get the codes. I have posted in the manual Exchange group on Yahoo and nobody has the Anritsu manual.
Too bad I'm not working at a place that uses GPIB any more. A few years ago I worked for a company that developed tape drives for data storage. We automated the parameter measurement for the read channels with MATLAB and a National Instruments GPIB. I could have borrowed one to check out my SLM. Oh well. Maybe I can touch base with some of my old cohorts and see if I can get access to a controller and some software for a couple of days.
A little off topic but all of this made something I have come to mind all of a sudden. In storage I have a HP 9815A desktop calculator that was used at a hospital in their "equipment service department", and there is an I/O card and cables with it. (Don't know if its HP-IB) Now I'm inspired to find this thing and dig it out. If I remember correct the vacuum display on the calc was very dim, and it was put on the to get to shelf but I never got to it. The thing stores and runs programs off little tapes and has a thermal printer.
A major difference between the 98xx models and the handhelds of the same period were the I/O devices and peripherals available. The HP 9815A could take data points from digitizers, plot data on pen plotters, print to thermal or daisy wheel printers and could read/write paper tape.
A BCD interface was available to allow the calculator to take samples from lab instruments and/or control them. An HP-IB interface allowed the calculator to be a controller of up to 14 instruments on the HP-IB bus. A general 8 bit I/O interface was also available.
Using a graphical interface is not necessarily a good thing. A Perl script may be exactly what you need where a complicated GUI would just be source of extra debugging headaches. One of my Perl scripts was used to drive a production line calibration setup. The user interface was a big green button (start), a big red button (stop/abort), a green LED (pass) and a red LED (fail). The calibration output was stored in the unit being calibrated, with a copy of the data written to a database and printed onto a label which was attached to the device at the end of a successful session. There was no keyboard, mouse or display screen.
Nothing I used in the project was proprietary. Even the interface between the PC and the buttons and LEDs was open source. The PC ran a LTS version of Ubuntu and was configured to boot straight into the calibration script. All the operator had to do was to turn on the PC and wait for the Green LED to light up (which was about 20 seconds). Additionally, it was all done for a fraction (my time included) of what NI would have charged the customer just for the required Labview licenses.
TonyC wrote:
In my case it would be very useful. I use this SLM for longwave beacon monitoring. Some of the best times to be listening for beacons is when I should be sleeping. I currently use other software to either record the audio for later playback through my SpectrumLab software or I use SpectrumLab to make periodic captures of the waterfall display which I can review the next day. The lack of receiver control forces me to park on one frequency for the entire night. This is not too bad but I would like to make sweeps through the longwave band automatically and that requires receiver control. The GPIB would give me what I need. It looks like the control software would be very easy to write for a task as simple as this.
A simple and free way to accomplish running through a few commands on your SLM would be Windows PowerShell. Here's a little blurb about it:
. Now, if I could just find some docs for my SLM.