[time-nuts] Getting GPIB to work on HP5382B Universal counter

[Dave Baxter]

Hi...

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.

First step...

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 this!  ;-)

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 misleading.
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
bidding.

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 from.


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..

Dave B.



> ------------------------------
> 
> 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
> 	counter
> 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 ideas)
> 
> 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.