> 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
|