Experimental Physics and
Industrial Control System

Carlos Pascual <[email protected]> · Mon, 17 Dec 2012 13:24:07 +0100

On Mon 17 December 2012 12:38:10 [email protected] wrote:
> From: [email protected] [mailto:tech-talk-
> 
> > If possible I would like to avoid such requirement of manually creating
> > the database.
> > 
> > By looking at the CA docs, I see that the IOCs emit periodic beacons,
> > so by listening for at least EPICS_CA_BEACON_PERIOD seconds I should be
> > able to gather a list of active IOCs. Is that right?
> 
> At Diamond I have created a tool which gathers a list of all PVs, but it
> relies on monitoring for CA_PROTO_SEARCH discovery messages, and so will
> only ever gather PVs which have at some time been requested.  Having run
> this tool for a couple of months our database of PVs has grown to 350,000
> entries!
> 
> The purpose of this tool is simply to answer the following question: "when
> a PV goes dead, which IOC was serving it?"  This is intended to be used to
> locate the appropriate IOC to restart when screens in the control room
> start to go dead.
> 
> This monitoring tool sits between the machine network carrying PV traffic
> and our internal database, which itself provides a web interface.  Each
> time a CA_PROTO_SEARCH message is seen for a new PV I add it to an
> internal table and create my own discovery message to locate the serving
> IOC; once found, an update is sent to our database and the PV is
> periodically refreshed.  Updates and retries are carefully throttled to
> avoid generating significant network load.
> 

Very interesting. A similar system but monitoring for CA_PROTO_RSRV_IS_UP 
instead of CA_PROTO_SEARCH would work for me provided that then I can get a 
list of PVs from a given IOC.

> > And if so, is there a way of interrogating a given IOC for its PVs?
> 
> In principle such a mechanism could be created, but I don't believe it
> exists at present. 

What do you mean by "could be created"? Do you mean that Epics could provide 
some API to this effect in the future?... Or that a way could be found to do it 
with existing APIs? ... or something else?

> To be honest, however, I suspect your requirement is
> back to front -- I don't see that there is a real need for a complete list
> of PVs on a network!

You are probably right in that I am attempting something not useful / needed 
by the Epics comunity. The problem may come from my Tango bias. Still, here is 
my justification: a typical use case of Taurus is that the user wants to create 
a TaurusForm widget [1] to display "Taurus Attributes". These "Taurus 
attributes" can be Tango Attributes or, recently, Epics PVs. In the case of 
the Tango Attributes, the user can invoke a tree [2] showing all the available 
attributes and dynamically add a choice of them to the widget. I just wanted 
to provide something similar for PV-based Taurus attributes.

[1] http://www.tango-
controls.org/static/taurus/latest/doc/html/users/ui/forms.html

[2]http://www.tango-
controls.org/static/taurus/latest/doc/html/users/ui/modelchooser.htm

-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 Cells / Alba Synchrotron  [http:/www.cells.es]
 Carretera BP 1413 de Cerdanyola-Sant Cugat, Km. 3.3
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: [email protected]
 Phone: +34 93 592 4428
+----------------------------------------------------+

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System