EPICS Controls 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  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  <19961997  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: rec/devSup advise needed
From: [email protected] (Gabor Csuka)
To: [email protected] (Ric Claus)
Cc: [email protected] (Gabor Csuka), [email protected]
Date: Thu, 22 Aug 1996 11:50:15 +0200 (MET DST)
Hi All,

Ric Claus wrote:
> 
> I'm writing driver, device and record support for a set of custom VXI
> modules.  These modules have several functions, but share a number of
> things like a subset of the VXI A16 registers, interrupt handling, etc.
> Because of the desire to keep things self consistent and efficient, I
> created one record type per module type.  This makes for fairly messy
> device support, as there is a lot of checking going on to figure out
> which record field changed that caused the record to process.  Does
> anyone have a cleaner way to deal with this?  Perhaps something to the
> effect of using RSET->special to figure out which field caused
> processing

 Your problem is more or less same as we had in DESY connected the 
 field bus 'devices' such as H1, CAN, Sedac, Profibus (CAN, Sedac,
 Profibus useing IP moduls)  Maybe our solution can help for the future.

 Our base decision was: 
  - write only devSupport routine for only the existing records.

  - add a new IO type (in link.h such as VXI_IO or VME_IO)
  - add a new member of the union of input/output descriptor
    in link.h  (The field contain the all module dependent information)
  - modify dct to handle this IO types.
  - use some common transport mechanisme standardise to writing
    the the device support routines.

 The status of this:
 ===================
 Interface:   Since:  IO           DevSup for records  Transport SCAN support
 SEDAC IP    1993   SEDAC_IO     ai/ao li/lo mbbi/mbbo CDI       time
 CAN IP	     1995   FIELD_BUS_IO ai/ao wi/wo mbbi/mbbo CDI       time IO_INT
 H1          1995   FIELD_BUS_IO ai/ao wi/wo mbbi/mbbo CDI       time IO_INT
                                 longin/longout   
 Profibus IP 1996   FIELD_BUS_IO same DevSup as H1     CDI       time IO_INT

For the IRM we use drvSupport routine as a fastest access to the IP board.
>From thid list is clear, we are the way somehow to use a common methode
for connecting a complicated interface for EPICS. 

Now we are planning:
====================
1.Modify dbStaticLib to handle the DESY IO types, and useing dbLoadRecord
 functionality. 
2.Paralell with this adding the same functionality to gdct
3.Useing the epics library (On Sun) adding the same functionality
 for our Oracle database application. 
4.Eliminate the wi/wo (written by DESY) records and useing the longin
 longout which is now working. 


Regards, 

Gabor CSUKA
-----------
DESY, Germany


Replies:
Re: rec/devSup advise needed Marty Kraimer
References:
rec/devSup advise needed Ric Claus

Navigate by Date:
Prev: Re: epics driver & device support for IP modules Andrew Johnson
Next: Re: epics driver & device support for IRM Gabor Csuka
Index: 1994  1995  <19961997  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: rec/devSup advise needed Ric Claus
Next: Re: rec/devSup advise needed Marty Kraimer
Index: 1994  1995  <19961997  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 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·