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

John Ackermann N8UR jra at febo.com
Sat Sep 10 08:34:30 EDT 2005


SRQ is definitely a pain, but is hard to do without if you're doing
anything with multiple instruments on the bus; my current problem is
trying to read frequency from a 5370A and voltage from the 3456A to plot
VCO performance.  Without the SRQ, I'm getting missing voltmeter readings.

Daun Yeagley, N8ASB, who hangs out on this list is a real GPIB expert
and he helped me get SRQ functionality going a while ago with three
5334A counters.  After a bit of dinking around, we were able to reliably
read all three counters as they made time interval readings available. 
The same setup should work here, but the problem I'm having is that the
3456A doesn't appear to be working the way it's supposed to.

According to the manual, sending "SM004" should cause SRQ to assert, and
set bit 2 of the status byte, when a reading is completed.  That doesn't
seem to be happening.  Nothing I've been able to do with the SM command
causes SRQ to assert.  I'm wondering if the manual is simply wrong about
how to set up the command -- which, given the errors and inconsistencies
we've found in the programming section of other HP manuals, wouldn't
surprise me a bit.

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!

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.

John


John
----

John Miles wrote:

>I just went through the whole SRQ annoyance with my phase-noise utility.  I
>was trying to use them to detect end-of-sweep conditions.  I ended up giving
>up on SRQs altogether in favor of using long (1000-second) timeout periods.
>
>They seemed kind of twitchy... if I remember right, the thing that finally
>made me give up was when I realized that I was getting SRQs immediately if
>any characters, including semicolons or CR/LF terminators, followed the TS
>(Take Sweep) command.  My code would think the sweep had ended immediately,
>and time out on slow sweeps waiting for the graph data request to complete.
>
>You're doing serial polling with ibrsp(), right?  Here's the code I was
>using (below).  GPIB_serial_poll() is a wrapper for ibrsp() in my GPIB
>library, while GPIB_status() just calls ibwait().  I was calling
>wait_for_SRQ() right after issuing the measurement command (TS in my case).
>
>I haven't had a chance to look at Dave Kirkby's code for the 3457 yet; maybe
>he's got the problem nailed...
>
>-- john, KE5FX
>
>
>//**************************************************************************
>**
>//
>// Wait for and acknowledge service request
>//
>//**************************************************************************
>**
>
>void acknowledge_SRQ(void)
>{
>   while (1)
>      {
>      if (GPIB_serial_poll() & 0x40)
>         {
>         break;
>         }
>
>      Sleep(10);
>
>      if (kbhit())
>         {
>         getch();
>
>         printf("GPIB serial poll interrupted!\n");
>         exit(1);
>         }
>      }
>}
>
>
>void wait_for_SRQ(void)
>{
>   while (1)
>      {
>      BOOL32 SRQ = FALSE;
>
>      while (GPIB_status() & 0x800)
>         {
>         acknowledge_SRQ();
>         SRQ = TRUE;
>         }
>
>      if (SRQ)
>         {
>         break;
>         }
>
>      Sleep(10);
>
>      if (kbhit())
>         {
>         getch();
>
>         printf("GPIB wait for SRQ interrupted!\n");
>         exit(1);
>         }
>      }
>}
>
>  
>
>>-----Original Message-----
>>From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com]On
>>Behalf Of John Ackermann N8UR
>>Sent: Friday, September 09, 2005 6:53 PM
>>To: Discussion of precise time and frequency measurement
>>Subject: [time-nuts] Off the wall: anyone with experience programming
>>HP3456A?
>>
>>
>>By any chance, has anyone here done any GPIB programming of the HP 3456A
>>DMM?  I am having great trouble getting it to output SRQ at the end of a
>>reading; it appears as though it simply doesn't recognize the "SM"
>>command that the manual says should be used to set the SRQ mask.
>>
>>Setting the mask with, e.g., "SM004" which according to the manual
>>should cause SRQ to be asserted at the completion of a reading, results
>>in the "004" being briefly displayed on the LED during setup, but no
>>sign of SRQ actually being asserted.  I've tried numerous values of the
>>octal code representing the status byte, but all act the same.
>>
>>I realize it's a long shot, but wonder if anyone here has wrestled with
>>this?
>>
>>Thanks,
>>
>>John
>>
>>_______________________________________________
>>time-nuts mailing list
>>time-nuts at febo.com
>>https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>
>>    
>>
>
>
>_______________________________________________
>time-nuts mailing list
>time-nuts at febo.com
>https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>
>
>  
>





More information about the time-nuts mailing list