1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: How to get a list of all available PVs |
From: | Alan Biocca <[email protected]> |
To: | [email protected] |
Date: | Mon, 17 Dec 2012 09:09:03 -0800 |
Hi Carlos,
No. As Mark Rivers has explained, most of the solutions people have been
On 2012-12-17 Carlos Pascual wrote:
> Are there any chances that something like this may end up being part of a
> base API in epics?
discussing just give you a list of record names. Each record has something
like a minimum of 40 different fields, so a typical 3.14 IOC with 1000 records
loaded could have anything from 40,000 up to maybe 200,000 possible PV names
that it would accept. Now multiply that by the 500 or more IOCs that machines
like the APS or SNS have and think about how much network bandwidth might be
used up in just one query for "*" (each name can be up to 65 characters long).
Furthermore one of the directions that we are moving in for 3.15 is to add
modifiable parameters to the PV name string, so for a 3.15 IOC the number of
PV names that could point to just one record can't easily be calculated.
That's why large EPICS sites have built database systems like IRMIS or Ralph
Lange's Channel Finder to make the current list of PVs available to clients or
users without disturbing the real-time systems while making such queries.
In your case I would think the Channel Finder might be the most useful, but it
does require that the names be loaded into the database. There's no way
around the fact that someone has to do the work somewhere.
HTH,
- Andrew
--
Computer science is as much about computers as astronomy is about
telescopes. -- Edsger Dijkstra