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

[John Miles]

> 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

Great summary, Dave.  This is one of the only pieces of advice I'd add a
caveat to -- specifically, that user-friendly error recovery in the GPIB
world can bloat your code at a geometric rate.  What does it mean, for
instance, if a write timeout happens on the 12th command in the 4th
iteration of a 20-command loop?  Did the timeout happen after the instrument
accepted the command, or before?  What *is* the instrument's state at this
point, anyway?  Should your program try to recover gracefully and offer the
user a chance to retry the operation... or is it better to terminate the
whole measurement and let the user recover from whatever unexpected
situation occurred in the outside world?

My own software sometimes fails on the side of recklessness, when a GPIB
error brings up an unhelpful error message and aborts the whole program.
That reveals its origin as a collection of quick and dirty hacks that were
never meant to be seen by the outside world.  Still, the code base would be
much larger and harder to maintain if I actually tried to implement good SW
engineering practices when talking to "stateful" hardware.

In newer applications I've at least broken myself of the habit of
terminating the whole .exe when something goes wrong, but I still don't
believe in taking extraordinary steps to handle errors.  Kill the current
measurement and let the user do the troubleshooting, IMHO.  Make a
distinction between robust, general-purpose code written for end users and
random hacks written to make your own life easier in the here-and-now.  They
both have legitimate places in your lab's ecosystem.

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

Better, however, to write the *code* for human consumption in the first
place.  Comments age like dead fish.  If you find yourself writing a long
comment to explain something, chances are you should go back and find a
simpler way to express it in the code itself.

-- john, KE5FX