Re: HP8116A signal generator

[Kate Feng <feng1@bnl.gov>]

Eric Norum wrote:

> First, a general reply to all the kind folks out there who wrote with  
> suggestions.  It's good to see that the EPICS community is still  
> hanging together.
> Second, to summarize the results, I'm still unable to get things to  
> work.  The plan is now to replace this obsolete generator with a more  
> modern piece of equipment. 

I do not  have the hardware and software, and
do not know what the IOC platform is. However,
there are two more things you can check for GPIB devices:

1) Some GPIB device driver uses the on-board DMA to transfer
command.  If so, one has to make sure that the "hardware
cache snoop" is on.  The howto depends on the SBC that is used.

2) There is a restriction on the total length of the cables in the
system.  One can isolate the problem by using the shortest
cable with only the targeted GPIB device attached to test.

Regards,
Kate

> On Nov 3, 2006, at 6:26 AM, David Maden wrote:
>
> > Eric Norum wrote:
> >
> > > All my memories of GPIB horrors are returning.
> > > I've put together ASYN/devGPIB support for an (obsolete) HP8116A   
> > > signal generator.  I'm trying  to  communicate with the generator   
> > > through an Agilent E5810A GPIB/LAN adapter.  As far as I can tell  
> > > I'm  sending the correct strings but the generator never acts upon  
> > > the  commands.  Every once in a very long while it will return a  
> > > status  message in response to a command, but most of the time it  
> > > just sits  there.  Once in a while it sets the SRQ line and then  
> > > leaves it set  forever.
> > > Does anyone out there have experience with HP8116A GPIB  communication?
> >
> >
> > Hi Eric,
> >
> > I have no experience with the HP8116A, but I do have quite a bit of  
> > experience of GPIB devices in general and the Agilent E5810A in  
> > particular. My experience has been that HP devices have well  behaved 
> > GPIB interfaces (not surprising really, since HP invented  the GPIB).
> >
> > I would suggest that you first try to understand how to communicate  
> > with your device using basic RPC calls to the E5810A before trying  
> > to tackle the complications of ASYN/devGPIB. You may find the  
> > program described at:
> >
> >    <http://www.sls.psi.ch/controls/help/howto/gpib_test.html>
>
>
> Thanks.
>
> I don't think that this is an ASYN/devGpib problem.  I tried to issue  
> commands through the web interface built in to the E5810A even then  
> was unable to get the 8116A to communicate.  I know that the 8116A is  
> capable of GPIB communication because it works with the PCMCIA GPIB  
> interface in a laptop.   I know that the E5810A is capable of  
> controlling devices because it can communicate with other devices on  
> the bus.
>
> > of some use when doing this, though I'm afraid that it won't help  
> > with SRQ issues. It is based on routines originally written by  
> > Benjamin Franksen of BESSY. You can find the code at:
> >
> >    <ftp://ftp.psi.ch/PSI_outgoing/maden/gpib_test.tar.gz>
>
> I downloaded and built this.  Here's what I get when I run it:
>
> 1) Try to read the complete settings from the 8116A:
> norume@worthy 366> GPIB_HOST=GPIB2GWDIAG1 GPIB_ADDR=gpib0,8 ./ 
> gpib_test sr CST
> device_read result  = 15 (I/O time-out)
> Bytes read          = 0
>
> 2) Try to read the frequency setting from the 8116A:
> norume@worthy 367> GPIB_HOST=GPIB2GWDIAG1 GPIB_ADDR=gpib0,8 ./ 
> gpib_test sr IFRQ
> device_read result  = 15 (I/O time-out)
> Bytes read          = 0
>
> 3) Try to read from another device -- it appears that the test  
> program and E5810A really do work:
> norume@worthy 368> GPIB_HOST=GPIB2GWDIAG1 GPIB_ADDR=gpib0,4 ./ 
> gpib_test sr "*IDN?"
> ICS Electronics, 4823B, S/N 011255, Rev X0.10 Ver 99.11.24\n
>
> 4) Try the 8116A again -- this time with a newline at the end of the  
> command:
> norume@worthy 369> GPIB_HOST=GPIB2GWDIAG1 GPIB_ADDR=gpib0,8 ./ 
> gpib_test sr "IFRQ\n"
> device_read result  = 15 (I/O time-out)
> Bytes read          = 0
> norume@worthy 370> GPIB_HOST=GPIB2GWDIAG1 GPIB_ADDR=gpib0,8 ./ 
> gpib_test sr "CST\n"
> device_read result  = 15 (I/O time-out)
> Bytes read          = 0
>
> 5) And again -- this time with a carriage return at the end of the  
> command:
> norume@worthy 371> GPIB_HOST=GPIB2GWDIAG1 GPIB_ADDR=gpib0,8 ./ 
> gpib_test sr "CST\r"
> device_read result  = 15 (I/O time-out)
> Bytes read          = 0
> norume@worthy 372> GPIB_HOST=GPIB2GWDIAG1 GPIB_ADDR=gpib0,8 ./ 
> gpib_test sr "IFRQ\r"
> device_read result  = 15 (I/O time-out)
> Bytes read          = 0
>
>
> Looks to be completely unresponsive.  :-(
> I could break out the GPIB bus analyzer and look into this further  
> but time constraints make it easier to just buy a replacement signal  
> generator.
>
>
>
> Oblibatory ASYN advertisement -- the asynRecord and associated MEDM  
> screens provide similar diagnostics for checking out GPIB communication.