Re: Bidirectional device support

[Luedeke Andreas <Andreas.Luedeke@psi.ch>]

Ernest L. Williams Jr. wrote:

> Can you achieve most of what you want by using a collection of database
>
> [...]
>
> Ernest
>  
Of course one can implement most or even all of the bi-directional
functionality using the existing record types. That was the start of the
discussion. But if you want to make heavy use of this feature in your
databases then you'll get big and opaque databases.
The question is: do we need this feature that often that these new
records should be part of EPICS base?

For me the answer is in some of the given arguments: the more smart
devices we have the more important it is to have these records. Because
due to the local intelligence you don't want to have a difference between
 - two or more clients modifying one channel or
 - clients or "hardware" sources modifying it.

It is difficult to explain to an operator why a corrector output channel
changes as long as an orbit feedback application is active and
doesn't change anymore when the orbit feedback DSP is taking over.
Todays physics applications are firmware!


But even if we decide to have it, the question remains how to do it.
For most databases I would need two independent links to my device support.
Sometimes it would be helpful to have a field to show, if the VAL field was
updated from the processing of the INP or the OUT link (by writing to VAL).
A "latency" field would be nice, to supress the update of the VAL field 
by INP
for a certain time period after a write to the OUT link, to make sure the
modification already took effect.
And it could be useful to disable modification from INP or from OUT 
permanently.
I'm always hesitant to add new record types, but I could actually make use
of the record types: aio, bio, mbbio, longio, stringio and waveio.

But of course I want someone else to do all that work ;-)
Should we postpone the discussion or is there a "potential volunteer"?

Andreas