Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: GP-IB extended addressing support.
From: winans@aps.anl.gov (John R. Winans)
To: noboru.yamamoto@kek.jp, tech-talk@aps.anl.gov
Date: Mon, 21 Oct 1996 14:47:47 -0500
>  I think I should sent this e-mail to the GP-IB device/driver support developer,
> but I'm not sure who is taking care of the code after John Winans has left APS.
> 
>  One of our users requested to support a GP-IB device which has extended
> secondary GP-IB address under EPICS. We currently use NI 1014 VME board and
> 
> drvGpib.c/devCommonGpib.c come with a base EPICS distribution. 
>  
>  I needed to make small changes in drvGpibInterface.h,devCommonGpib.h, drvGpib.c
> and devCommonGpib.c to support GP-IB secondary address. When modified
> version of devGpibLib_initXx routine get the device number greater than 100
> from database, it interprete it as device= 100* primary + secondary and
> store it into (modified version of ) hwpvt structure. "readIb/writeIb"
> takes additional argument, "int secondary" at the end of its arguments and
> use it as extended GP-IB secondary 
> address if it is not -1. With these modification, I could access a GP-IB
> device which has multiple secondary addresses.
> 
>  Unfortunately this modification cannot handle SRQ request from a GP-IB device
> which uses the extended addressing. I have no idea to expand arrays in
> ibLink structure, such as srqHandler[IBAPERLINK], for extended addressing
> scheme.


This came up a while back.  The requestor left ANL before any work was started
to support the request.  Your proposed solution is similar to the one I was
going to use (I was going to use 0-31, 32-63, ...)  

I asked about SRQs at that time and we never decided wht to do.  It just so
happens that noone at APS ever used SRQs for anything anyway.  (we always set
ibSrqLock=1 in the startup.cmd files.)  So I have not put any real time into 
dealing with them.  If I was you and I did not require the use of SRQs, I 
would simply state that "they are only supported in serial poll mode to the 
primary addresses."  And leave it as that.  

If you need the SRQs in your system, and you need some special polling, then
you will have to rework the polling logic in the driver somehow.  It has been
a while since I read the book, but I thought SRQs are only relevant to the
primary adresses anyway... it is the SRQ handler that should be specialized.
And if that is the case, the current SRQs are probably acceptable.

--John Winans


Navigate by Date:
Prev: CA c++ class library? Carl Lionberger
Next: Re: Force Sparc 5 Performance Tests Peregrine McGehee
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: GP-IB extended addressing support. Noboru Yamamoto
Next: EPICS training Bob Dalesio
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·