[time-nuts] Off the wall: anyone with experience programmingHP3456A?

[John Miles]

> By the way -- your wait_for_SRQ routine is a bit different than mine in
> that you're testing for 0x800 while I'm calling the board (not the
> device) with the iblines command and looking at 0x2000 to test bit 14,
> the "busSRQ" signal.  I'm using the linux-gpib package, which in theory
> mimics the NI library functions, and the perl function bindings it
> provides.  The perl functions didn't include anything that would allow
> me to check the SRQ status, so Daun helped me come up with that test,
> which seems to work well.
>
> I basically check for 0x2000 on the board, then if true a serial poll of
> the instrument, then if that returns 0x40, read the instrument.  That
> sequence seems to work OK, if I can get the instrument to set SRQ when
> it's supposed to!

Good info, thanks.  I'll have to look at that iblines() function in the
manual... I've never used it for anything.

>From what I can tell, the appeal of SRQs lies strictly in the ability to
create a polling loop that can keep busy doing other work, like rendering
data from a previous sweep, checking for abort requests from the user, or
reading data coming in from another instrument.  None of those tasks was
relevant to what I was doing, although it's sure nice to be able to respond
instantly to an abort request.

I imagine you could use independent threads to wait for readings from
different instruments.  The quick and dirty GPIB wrapper library I wrote
isn't amenable to multithreading, so I didn't investigate that.

Hopefully the RAM chip will be the cause of the weirdness you were seeing.
Again, I never had problems receiving and acking the SRQ -- it was more a
matter of getting them at unexpected times.  With enough tinkering, I could
figure out what my own 8566B was actually doing and work around its quirks,
but I was trying to get the same code running on an 8563E in Texas at the
same time, and the SRQ situation seemed like more trouble than it was worth
in that case.  I felt bad about sending version after version to the guy
with the 8563E with "OK, what does THIS one do?"

> One other thing we've found, particularly with the older HP instruments,
> is that you often need to insert a sleep of anything from 500uS to 5ms
> after issuing a command before sending another command.

Interesting; I hadn't run across that.  The examples in the manuals commonly
show multiple commands in a single string; maybe the old-school BASIC
controllers were smart enough to pause briefly after transmitting semicolons
or string terminators...?

-- john, KE5FX