| 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 process variables, linux alarm handler |
| From: | Matthieu Bec <[email protected]> |
| To: | Don Dohan <[email protected]> |
| Cc: | [email protected] |
| Date: | Tue, 15 Sep 2009 00:07:08 -0400 |
Hi,That certainly is a good read (I think would deserve an entry in the appdev guide or epics wiki)
independently of DBR_ type you use with channel access considerations and I suspect other PCAS channels consideration that might be yet another discussion:
does the pv crawler used for the IRMIS RDB let you differentiate: instance_of_old_kind_xxx_record <that does not have a .YYY field>instance_of_new_kind_xxx_record <that has the new .YYY field, but use the default>
Matthieu On 09/14/09 23:20, Don Dohan wrote:
The last cut and paste didn't make it: Kay discusses the relationship between PVs, records and names at http://www.aps.anl.gov/epics/tech-talk/2007/msg00853.php Don On 9/14/09 11:18 PM, "Don Dohan"<[email protected]> wrote:If you mean the pv crawler used for the IRMIS RDB, the crawler extracts and stores both the record name and user defined field type instance values. The crawler maintains a link to the dbd file used in defining each record, making it possible to reconstruct the full record using both user defined field values and default field values. PVs, however are still something a little different - see Kay Kasemir's explanation On 9/14/09 9:09 PM, "Matthieu Bec"<[email protected]> wrote:Hi all, I'm having a terminology issue someone might help with, because the comments posted on this thread appear to mix 'record' and 'PV' terminology interchangeably. Most of the time it's clear, and although there is a reasonable '1 to n' relation between the two, I can think of example that relation can break. To give an example, say: ioc1 uses old xxx record type, that does not have .YYY field ioc2 uses new xxx record type, that has a new .YYY field xxx 'record' (dbl/dbgrep etc) report the same thing. but ioc2 use a newer version that might add/remove some fields (that I think is what we really call PV = I think of it as the entity you get over channel access) So what does pvCrawl really look at: PVs or records? does it figure in my example field .YYY exists in ioc2 but not ioc1? Thanks Matthieu
-- Matthieu Bec Gemini Observatory Tel: +56 51 205785 c/o AURA, Casilla 603 Fax: +56 51 205650 La Serena, Chile