Experimental Physics and Industrial Control System
|
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.
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
- Replies:
- Re: BI-Directional PVs Marty Kraimer
- References:
- BI-Directional PVs David H. Thompson
- Re: BI-Directional PVs Marty Kraimer
- Navigate by Date:
- Prev:
Re: BI-Directional PVs Marty Kraimer
- Next:
Re: BI-Directional PVs Marty Kraimer
- 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:
Re: BI-Directional PVs Marty Kraimer
- Next:
Re: BI-Directional PVs Marty Kraimer
- 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
|
ANJ, 10 Aug 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|