Re: How to get a list of all available PVs

[Till Straumann <strauman@slac.stanford.edu>]

Here is a link into the relevant thread

http://www.aps.anl.gov/epics/tech-talk/2008/msg00437.php

This:

http://ics-web4.sns.ornl.gov/pvlistserver/log/show.php?mon=Apr&theDay=30&year=2004

seems to implement what has been suggested earlier (simple protocol which conveys a list
of PVs hosted on an IOC). It does require building and running a separate server
on every IOC, though.

HTH
- Till


On 12/17/2012 09:56 AM, Williams Jr., Ernest L. wrote:

Hi
When I was at the SNS, John Sinclair wrote a nice tool
Please refer to the following tech-talk entry:
====================
Subject:        RE: Listing channels
From:   "Thompson, David H." <thompsondh@ornl.gov<mailto:thompsondh_at_ornl.gov>>
To:     tech-talk@aps.anl.gov<mailto:tech-talk_at_aps.anl.gov>
Date:   Thu, 08 May 2008 14:49:36 -0400




Sent from my iPhone

On Dec 17, 2012, at 7:43 AM, "Carlos Pascual" <cpascual@cells.es<mailto:cpascual@cells.es>> wrote:

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, michael.abbott@diamond.ac.uk<mailto:michael.abbott@diamond.ac.uk> 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<http://www.cells.es>]
Carretera BP 1413 de Cerdanyola-Sant Cugat, Km. 3.3
E-08290 Cerdanyola del Valles (Barcelona), Spain
E-mail: cpascual@cells.es<mailto:cpascual@cells.es>
Phone: +34 93 592 4428
+----------------------------------------------------+