EPICS Controls 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  2020  2021  2022  2023  2024  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  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: BI-Directional PVs
From: Marty Kraimer <[email protected]>
To: "Ned D. Arnold" <[email protected]>
Cc: "David H. Thompson" <[email protected]>, techtalk <[email protected]>
Date: Mon, 17 Feb 2003 13:13:03 -0600
Ned D. Arnold wrote:

What would be really helpful in the implementation of this requirement would be to have the VAL field of the record specified as a "special(SPC_MOD)" field. You can then add a routine in record support that is called only when a CA Client changes the value. This would make it quite easy to arbitrate between shared memory changes and CA client changes.




Database links to the record.field will also cause the special routine to be called. Thus SPC_MOD can not be used to determine if a CA client did the put.

PUTF can also not be used to determine if a CA client did the put.
Assume a CA client does a put to record A which forwards to record B which is connected to shared memory (the database designer wants to do some processing on the value the user gives). PUTF doesn't provide the info desired.


Again let the shared message device/driver support specify that IT has requested record processing because it detected that shared memory changed value.

Marty


This would necessitate a custom record type, but it could be VERY similar to one of the input records you are considering.


Ned




Marty Kraimer wrote:

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









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

Navigate by Date:
Prev: Re: BI-Directional PVs Ned D. Arnold
Next: Re: BI-Directional PVs kuner
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  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: BI-Directional PVs Ned D. Arnold
Next: Re: BI-Directional PVs kuner
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  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 ·