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] (Tim Mooney)
To: [email protected], [email protected]
Cc: [email protected]
Date: Thu, 22 Aug 1996 11:17:28 -0500
Ric, re...

> 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
> and using that information (somehow) to tell RSET->process which
> DSET->process
> function to call?  Perhaps call DSET->process in RSET->special directly?

I've used special() just as you've described to simplify record-support
code.  Give your record a field you can use as a bitmap, e.g.

	"Monitor Mask" MMAP SPC_NOMOD ASL1 DBF_ULONG NO	3 ...

In special(), set the bit associated with the field that has changed:
	.
	.
	#define	M_MRES		0x00000080
	#define	M_ERES		0x00000100
	.
	.
	static long special(struct dbAddr *paddr, int after)
	.
	.
	if (paddr->pfield == (void *)&pmr->mres) pmr->mmap |= M_MRES;

>   Second, the records properly handle Is and Os from/to the modules when
> they are marked scan passive.  However, the modules can also raise 
> interrupts when they detect faults.  I would like to get that
> information
> into record fields for display on an operator screen.  Setting up for
> the I/O Event scan mode appears to lock out processing due to
> modification of record fields from operator screens.

One possibility is to use an EVENT record with SCAN = "I/O Intr" to
detect the interrupt and forward link to the scan-passive record.

Tim


Navigate by Date:
Prev: Re: rec/devSup advise needed Andrew Johnson
Next: R3.13 App Devl Guide Janet B. Anderson
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: Re: rec/devSup advise needed Marty Kraimer
Next: Re: rec/devSup advise needed John R. Winans
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 ·