Hi Matthieu
Yes, the crawler captures the differences in the record definitions in your
example.
The rec_name/fld type values are also archived in the RDB across ioc
reboots, giving a complete snapshot of all records for all iocs at any time.
This means that in principle one could compare record definitions for a
record whose definition changes as in your example, even for the same IOC.
This is handy for fixing IOCs that break when a record definition is changed
- even if the .db logic is unchanged.
Don
On 9/15/09 12:07 AM, "Matthieu Bec" <[email protected]> wrote:
>
> 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
>>
>
- References:
- Re: list all process variables, linux alarm handler Matthieu Bec
- Navigate by Date:
- Prev:
Re: list all process variables, linux alarm handler Matthieu Bec
- Next:
Re: MBBO Record Initialization Ned Arnold
- 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
- Navigate by Thread:
- Prev:
Re: list all process variables, linux alarm handler Matthieu Bec
- Next:
Patch for alarm.h in 3-14-11 David Dudley
- 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
|