Re: BI-Directional PVs

[Marty Kraimer <mrk@aps.anl.gov>]

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