EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: V4 Database Access
From: "Jeff Hill" <[email protected]>
To: "'Ralph Lange'" <[email protected]>, "'EPICS Core Talk'" <[email protected]>
Date: Wed, 15 Jun 2005 17:54:37 -0600
When the CA client library runs inside the IOC it communicates with the
database service directly (w/o going through a socket). The client library
also communicates directly with the IOC's event queue. Considering that, and
considering that the new client interface and the new service interface will
be very close to identical then perhaps we can conclude that your vampire
can insert its fangs using the CA client library interface. Or in any case
we should probably invalidate that approach before defining a new interface.

Jeff

-----Original Message-----
From: Ralph Lange [mailto:[email protected]] 
Sent: Wednesday, June 15, 2005 8:47 AM
To: EPICS Core Talk
Subject: V4 Database Access

Another thing that I recently found missing:

I think we agreed to introduce APIs between the IOC database and the CA 
server that allow
 - other (network) servers to register with the database (as listeners 
being interested in getting events)
 - other (database kind of) things to register as a new provider of 
"records" (i.e. named DA property catalogs)

Where's the new thing (module, service, handler?) that provides these 
interfaces?

Seen from 3.14, this takes over some of the functionality that has been 
in the database and some from Channel Access.
It should handle record name resolution and connection to DA interfaces 
(to handle requests coming in from servers).
It should also work as an event handler (broker?) that software modules 
(like a server or the Vampire) can subscribe to and the database can 
post its events to that get distributed to the registered listeners.

I'm not sure about the design as all this definitely sounds like a local 
cut-down version of channel access. If we introduce client-specified 
monitor deadbands - should handling these deadbands by client be moved 
from CAS down into that layer to make it available for other 
transports/servers?

I'm not trying to impose anything here ... it's just that the Vampire 
needs to intercept db_post_event() and add more channels to the IOC 
record namespace, and I don't know at which level that would be done.

Cheers,
Ralph



References:
V4 Database Access Ralph Lange

Navigate by Date:
Prev: RE: V4 Data Types: Request for tagged unions Jeff Hill
Next: RE: V4 Database Access Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: V4 Database Access Ralph Lange
Next: Re: V4 Database Access Ralph Lange
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·