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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: BI-Directional PVs |
From: | "Ned D. Arnold" <[email protected]> |
To: | "David H. Thompson" <[email protected]> |
Cc: | techtalk <[email protected]> |
Date: | Mon, 17 Feb 2003 09:36:37 -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