EPICS Re: GP-IB extended addressing support.

Experimental Physics and Industrial Control System

1994 1995 <1996> 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024	Index	1994 1995 <1996> 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
<== Date ==>		<== Thread ==>

Subject:	Re: GP-IB extended addressing support.
From:	[email protected] (John R. Winans)
To:	[email protected], [email protected]
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 <1996> 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
Navigate by Thread:: Prev: GP-IB extended addressing support. Noboru Yamamoto; Next: EPICS training Bob Dalesio; Index: 1994 1995 <1996> 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024