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: Ralph Lange <[email protected]>
To: EPICS Core Talk <[email protected]>
Date: Mon, 20 Jun 2005 14:02:03 +0200
Hm ...

I'm repeating my question of last week:

A piece of IOC code (here: the Vampire) wants to
1. Add channels to the IOC (outside of the EPICS Database) that can be accessed through CA (or other network services). 2. Intercept events that are posted from the EPICS Database to CA (or other network services).

How does my code achieve this? Where does it have to register? Using which interface? Which module is taking care of this (IOC name resolution, event handling)?

Am I right that these issues (maybe together with adding trigger info, aka "coloured beam" things) are located in something that Bob called "Middleware" in the meeting notes that he distributed last month? So that these things are part of the APS work package?

Sorry - I'm not trying to push, I just don't know where to expect these things...
But - to avoid possible misconception - I'm not volunteering either... ;-)

Cheers,
Ralph


Ralph Lange wrote:

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: Fundamental Types document / unsigned integers Benjamin Franksen
Next: Re: Fundamental Types / Gateway 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 
Navigate by Thread:
Prev: RE: V4 Database Access 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 
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 ·