EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  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  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Bidirectional device support
From: Luedeke Andreas <[email protected]>
To: "Ernest L. Williams Jr." <[email protected]>
Cc: Ralph Lange <[email protected]>, EPICS Tech-Talk <[email protected]>, Andrew Johnson <[email protected]>
Date: Tue, 13 Apr 2004 15:31:40 +0200
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


References:
RE: Bidirectional device support Liyu, Andrei
RE: Bidirectional device support Ralph Lange
RE: Bidirectional device support Ernest L. Williams Jr.

Navigate by Date:
Prev: Re: Extensions configuration/compilation David Decotigny
Next: RE: Bidirectional device support Carl Lionberger
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Bidirectional device support Ernest L. Williams Jr.
Next: RE: Bidirectional device support Robby Tanner
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  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 ·