Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: BI-Directional PVs
From: Marty Kraimer <mrk@aps.anl.gov>
To: "David H. Thompson" <thompsondh@ornl.gov>
Cc: techtalk <tech-talk@aps.anl.gov>
Date: Mon, 17 Feb 2003 09:09:03 -0600
David H. Thompson wrote:
My application is device support into a shared memory area that other,
non-epics, processes interact with.  The application needed for some of the
PVs in shared memory to be adjusted either from a remote location via
channel access or locally from the shared memory client application.  The
user wanted to be able to monitor the data in shared memory and also be able
to set the value there via the same PV.  I am using IOC core, (3.14.1 on a
windows platform) instead of a CA Server.

Looking at record support for ai,ao, long in and out, and binary in and out,
as well as waveform, it seems that "input" records provide the best way to
support bi-directionality in IOC core since record support there does little
to the record before calling the input routine in device support.

I also noticed in the record reference manual that the PUTF field is a
logical that happens to be set if dbpf, or channel access, is writing a
value to the record and if SCAN is passive.  This lets the device support
know that data should be written instead of read.  Scanning can be
accomplished by using an flink from something that is scanning, say a
fanoutRecord.

Question: Who else has done this and if so is there a better way to do it.
What am I missing?


I don't think you should use the PUTF field. It is for internal use by dbAccess.


I think your goal is the following:

Implement device support that connects EPICS records to shared memory.
If a CA client writes to the record then a write to shared memory should occur. If a shared memory location changes value than a value should be read from the shared memory and put in the record.


Why not do the following:

As you suggested implement device support for input records, i.e. aiRecord, biRecord, mbbiRecord, etc.

Keep a field that determines if device support should read or write the shared memory. It is normally set to write. When you have detected that shared memory has changed, set this field to read and ask that the associated record be procesesed.

Note that callbackRequestProcessCallback can be used to request processing.


Marty Kraimer



Replies:
Re: BI-Directional PVs Ned D. Arnold
References:
BI-Directional PVs David H. Thompson

Navigate by Date:
Prev: CEXP-1.2 ("valentine") released Till Straumann
Next: Re: BI-Directional PVs Ned D. Arnold
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: BI-Directional PVs David H. Thompson
Next: Re: BI-Directional PVs Ned D. Arnold
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
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 ·