Experimental Physics and
Industrial Control System

Tim Mooney <[email protected]> · Mon, 17 Dec 2012 12:42:52 -0600 (CST)

Hi Carlos,

I think you should not be stopped by the lack of a generic source of
PV names.  It's easy enough to make such a list that anyone who wants
to try out Taurus could get the required code installed in all the IOCs
they cared about.  There are code snippets all over the place that
accomplish parts of what would be required, including code to collect
records names that fit a specified pattern, and code to find all the
fields associated with a given record type.  Not all of this is readily
available via channel access, but it would be easy to write a python
module that collected all the PV names for, say, a synchrotron beamline.

In actual practice, however, I'll guess that a complete list of PVs for all
the IOCs on a beamline would not be what a Taurus evaluator would want.
Most (maybe 99%?) of EPICS PVs are not intended ever to be written or read
by end users or clients, but instead are merely implementation details
supporting the 1% of PVs that *are* intended for client access.  If I had
a Python list of those PVs, and downloaded a copy of Taurus, what would be
my next move?

Tim

----- Original Message -----
> From: "Carlos Pascual" <[email protected]>
> To: [email protected]
> Sent: Monday, December 17, 2012 9:43:26 AM
> Subject: Re: How to get a list of all available PVs
> Thank you all for your replies,
> 
> So far I conclude that it is possible to make use of thebeacons to
> build a
> list of the IPs and ports of the existing IOCs.
> 
> But then I can only go from IOCs to Records and/or PVs by modifying
> the code
> of all the IOCs (or of the launcher scripts of those IOCs).
> 
> This last part is kind of problematic to me since I cannot assume that
> it will
> be done in all facilities. Note that I am not looking for a solution
> for my
> facility (we use Tango) but instead we want to provide a library that
> can be
> used on top of any existing installations elsewhere...
> 
> In other words: I don't think I would convince anyone to try out
> Taurus on
> epics if a requirement was to have to modify all the IOCs... ;)
> 
> Are there any chances that something like this may end up being part
> of a base
> API in epics?
> 
> Cheers,
> 
> Carlos
> 
> 
> 
> On Mon 17 December 2012 15:35:05 Ralph Lange wrote:
> > On 17.12.2012 14:52, [email protected] wrote:
> > > [...]
> > > One or the other, I've not looked to see what would be involved
> > > (well, I
> > > have now...). I'd start by thinking of providing a simple socket
> > > interface which walks the database, or maybe just returns the
> > > results of
> > > dbgrep.
> > >
> > > Actually, a glance at the implementation of dbgrep
> > > (src/db/dbTest.c)
> > > suggests that the existing code is close to what you need, but
> > > needs a
> > > tweak (rather than calling puts you'll want more control over
> > > where the
> > > strings go), but it looks to me as if all the functions called by
> > > dbgrep
> > > are exported by epics, so writing what you need should be
> > > exceptionally
> > > easy: just grab a copy of dbgrep, give it a file handle output,
> > > replace
> > > puts, wrap a socket interface around it, launch it as part of your
> > > IOC
> > > startup scripts.
> > >
> > > If it were me, I'd dedicate a socket, read one line from the
> > > input, treat
> > > it as input to the modified dbgrep, send the results in response,
> > > close
> > > the socket. Then `echo \* | nc $IOC $PORT` would give you a list
> > > of all
> > > PVs exported by the IOC.
> > >
> > > Of course, you'll need to add this code to every IOC...
> >
> > You could also create a device support for the waveform record, that
> > (at
> > boot time) creates an array (of char) containing all records' names.
> > Then a client can simply use CA to get the complete list from an
> > IOC,
> > and there is no runtime overhead on the IOC. (Usually the client
> > will be
> > faster at doing wildcard matches anyway.)
> >
> > ~Ralph
> 
> --
> +----------------------------------------------------+
> 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
> +----------------------------------------------------+

-- 
Tim Mooney ([email protected]) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System