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: List all available PVs |
From: | "Kasemir, Kay via Tech-talk" <tech-talk at aps.anl.gov> |
To: | EPICS Tech Talk <tech-talk at aps.anl.gov>, Stainer Tom <Tom.Stainer at sckcen.be> |
Date: | Tue, 27 Apr 2021 12:41:09 +0000 |
Hi,
> For my simple example, to follow up, *pvlist*
does not work (for me) without any arguments – it returns nothing.
...
> I noticed no equivalent *calist* tool exists, is there a specific reason for this?
I'd say in part that's because the EPICS network protocol is meant to be loosely coupled, kinda like web servers. Anybody can start a new web server, email the URL to a friend, who can then open the new web page. Similarly, you can start a new IOC, give the PV name to a friend who can then access the PV. Out of the box, there is no need to add your web server to a central registry, just like there is no global EPICS PV name server. There's also the question of what an IOC should publish for possible channel names, since in principle every record_name.field_name permutation can be a channel name, but many record are meant to be 'internal', not intended to be shown on a display. With web servers, Google will read the email that you send to your friend and put your new web site into its index, so there is pretty soon a way to locate your web site. Similarly, most EPICS sites add some service on top of IOCs to catalog PV names into for example the Channel Finder. But those are layers on top of the basic web page or IOC, you're still free to add web server or IOC or just a new record to an existing IOC without need to "register" it.
-Kay |