[time-nuts] Getting GPIB to work on HP5382B Universal counter
David C. Partridge
david.partridge at dsl.pipex.com
Wed Oct 14 09:27:22 UTC 2009
I don't remember being your college tutor on this - in fact I never was a
college teacher, but what you've laid out below is pretty much what I taught
all the trainee programmers I had. You've done a very good job of putting
it "in a nutshell".
The objective of the whole is to achieve understandability so that the next
poor sap (this might be you two years later) who comes along to work on this
thing (whatever it is) can get stuck in to fix it without having to reverse
engineer the thought processes of the original author.
From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On
Behalf Of Dave Baxter
Sent: 14 October 2009 10:15
To: time-nuts at febo.com
Subject: Re: [time-nuts] Getting GPIB to work on HP5382B Universal counter
I use mostly NI GPIB cards & adapters, but from the little work I've done
with the HP/Agilent stuff, I think the same overall principle applies, re
software development for instrument control.
Install the USB<>GPIB adapter drivers, tools and utilities "Exactly" as the
instruction say to for whatever OS you are running. Run and verify any
diagnostics they supply too. If anything does not work as expected, find
out what and why.
Then, in the folder tree all that will probably create somewhere on your
system, there will be some documentation, and probably some worked examples
in various languages, VB, C, Delphi etc, as to how to do the basic (as in
simple) IO communication stuff. NI is particularly good in that respect,
it's been a while since I hand hands on, of any Agilent kit like this.
Look around the web. You will not be the only, or first person to be doing
Don't expect older kit to conform to the more usual these days IEEE488.2
command structures, or SCPI for example. Modern more complicated protocols
are often not intuitive to mere mortals, some can even be downright
In particular, do not expect some older kit to respond to '*IDN?' (an
identity query) Some will just take for example a command 'ID'.
Do not expect instant results/success! It takes a lot of time and
effort to often "reverse engineer" someone else's code (even simple
stuff) so you "Fully" understand how and why it works. Take the time
needed, it'll pay off in the long term.
Try to first talk to/control a much simpler bit of kit, or only do very
easy predictable stuff with it, if you only have one instrument. The
only "Libraries" you "Need" will be the ones supplied for your programming
language, to talk to and control the GPIB controller.
Do not expect the instruments manual to tell the whole truth, in regards to
it's GPIB functions. Some books are good (older HP for instance)
some are totally useless, written by accountants I think. Understand
how to use the instrument manually first also helps a great deal.
(Something along the lines of know your enemy!) Many manuals have
minor errors, that though experienced programmers and users will spot, cuss,
and carry on, if you do not have that "time served" experience,
they can stop you dead in your tracks. Common misprints, in nth
generation photocopies and scan's for example, commas that look like
periods, semi-colons that look like colons etc...
VB though you can get some versions for free, is probably not the best
choice for instrument control (or anything else some would say) But it
can be very useful. Try to find the exact same version, as
Agilent/HP/NI used in their examples. MS are terrible for changing small
details that often cause show stopping problems when trying to do things
like this, especialy if you're trying to "learn how to" at the same time.
Despite what all the hype will say, do not expect it to be "Easy" or "Quick"
(whatever programming language you use, and I include LabView in that
respect too!) Programming, and doing it well, in any language, for whatever
reason, takes time and thought to get "Just Right", so that all
circumstances are covered. Something that many programmers seem not to
appreciate. What I mean, is expect errors from the instrument, and the
users input (often you!) and make the program robust enough to catch and
handle them safely.
IF a condition is met (or not)
THEN do something you want
ELSE take care of any unexpected conditions!
As my old college tutor kept trying to drum into us, the programs purpose
and function should be easily read in the comments. The "code"
is the translation from your comments, to get the machine to do your
Document what you do, in the source comments, line by line at times!
You'll save a lot of time when you come back to something later, even only a
few days time!
Split your code into logical segments, subroutines, modules whatever.
Add plenty of "white space" in the source code, it makes reading it so much
easier, and also modifying it later too..
One module for example, to handle the GPIB interface.
So if you ever give the code to someone else, or you get another PC with a
different GPIB system, it's only that part that needs re-writing.
Likewise, a separate module for any RS232 IO for example, if/when needed.
Another to handle IO to/from the instrument, this can be for each individual
instrument, or a common module for several similar instruments. Most
instruments you can query to find out what they are, reporting back the
model number and often any firmware version. Most useful!
Another to do the "guts" of what you want.
Where eventually you'll spend most of your time and effort.
Processing measurement data, doing the "experiment" in essence...
And finally, one to handle the user interface, all the pretty bits etc.
Where you can "personalise" it to your taste.. This is usually the
first one to be made, in most GUI aware language tools, often much of it
is done for you when you make the on screen form. Again, VB (if that
is what you end up using) will have many worked examples for you to learn
The modular approach, does also make it quicker and easier later to make a
new software tool or experimantal process, using the same IO but with a
different instrument, or the same instrument in a different way.
Take your time, don't overdo it, and eventually you'll have that warm fuzzy
happy feeling, when all of a sudden, the instrument is doing your
beck and call from your software, and doing it reliably!... It's I
think second only to rebuilding a dead engine, and the happy time when it
first bursts back into life again!
If you get "stuck into it"... Expect complaints from partners family (or a
persistant hungry cat) as the time will just fly by...
Keep a pencil and notepad by the bed. You'll wake up in the middle of the
night, knowing exactly what and how to solve some problem you were working
on, write it down, draw a sketch whatever & however strange it may be, and
then you'll remember it in the morning! ;-)
Above all Enjoy! If it's not fun, don't do it, unless someone is
paying you plenty to do so!
Regards to all..
> Message: 7
> Date: Tue, 13 Oct 2009 16:07:38 -0700
> From: Hal Murray <hmurray at megapathdsl.net>
> Subject: Re: [time-nuts] Getting GPIB to work on HP5382B Universal
> To: Discussion of precise time and frequency measurement
> <time-nuts at febo.com>
> Message-ID: <20091013230739.58C8DBCFC at ip-64-139-1-69.sjc.megapath.net>
> Content-Type: text/plain; charset=us-ascii
> > I'd very much appreciate any help that I can get in setting up a
> > HP5328B to communicate over GPIB. The goal is to log/graph the
> > frequency over time of various VFO's projects I'm working on.
> > I am using the Agilent 82357A USB to GPIB Interface, I have
> the manual
> > for the counter, so I know some of the basic GPIB commands. I've
> > downloaded the Agilent IO Libraries Suite 15.5 and it looks
> like I can
> > send simple commands to the counter, but I am not having any luck
> > reading from the counter.
> > I'd like to use Visual Basic to send commands and receive the
> > frequency measurements... but need some HP5328B specific libraries?
> I haven't worked with either the 82357A or HP5328B. I have worked with
> similar gear.
> I doubt if you need any HP5328B specific libraries.
> Do you have any documentation for the libraries you are using?
> There may be some initialization magic that you need to do.
> Can you find any examples using the 82357A and the libraries you have?
> (even if they talk to another type of box, they may give you some
> What makes you think you are sending commands? Do lights blink or
> such? Or just that your program doesn't hang?
> If I was debugging something like that, I pick the simplest example I
> could find and work on it.
> There is probably a reset command. It might blink some lights but it
> doesn't send back any data.
> There is probably an ID command to tell you what type of device you
> are talking to. If you can get that to work you are over the hump.
> Sometimes things like this are timing sensitive. A delay of 10 or 100
> ms after each send might help.
> These are my opinions, not necessarily my employer's. I hate spam.
time-nuts mailing list -- time-nuts at febo.com
To unsubscribe, go to
and follow the instructions there.
More information about the time-nuts