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: "Liyu, Andrei" <[email protected]>
To: Luedeke Andreas <[email protected]>, "Williams Jr, Ernest L." <[email protected]>
Cc: Ralph Lange <[email protected]>, EPICS Tech-Talk <[email protected]>, Andrew Johnson <[email protected]>
Date: Tue, 13 Apr 2004 12:48:58 -0400
Andreas 

================
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.
=================
>From my vision this again connects to server-detectors structure in
server (IOC) and Epics hasn't it. So
- each detector has two arrays - input parameters and output parameters
+ data
- server (not detector) connects to clients and put new input parameters
to detector's input parameters array (of course, server and detectors
have different threads and use sync). 10 clients set new data and server
changes parameters 10 times
- detector works in cycle 
	- set new parameters
	- does measurements with new parameters

In this case server has equal access for each client. But if any client
would like to have single driving server level should support it.

Thanks, Andrei.



-----Original Message-----
From: Luedeke Andreas [mailto:[email protected]] 
Sent: Tuesday, April 13, 2004 9:32 AM
To: Williams Jr, Ernest L.
Cc: Ralph Lange; EPICS Tech-Talk; Andrew Johnson
Subject: Re: Bidirectional device support

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



Navigate by Date:
Prev: RE: Bidirectional device support Liyu, Andrei
Next: Re: Extensions configuration/compilation Janet Anderson
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 Liyu, Andrei
Next: RE: Bidirectional device support Thompson, David H.
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 ·