At 10:42 AM 8/27/2001, Benjamin Franksen wrote:
>Kay-Uwe Kasemir wrote:
>>
>> First the part that got me confused and I know from emails that I'm not the only one:
>> lopr, hopr, hihi, ... are epics record fields.
>> CA talks about display limits, alarm limits, ...
>> That's different.
>>
>> When you ask an ai record fred for "fred",
>> the value is the VAL field, display limits are HOPR, LOPR,
>> alarm limits are HIHI, LOLO, warnings are HIGH, LOW, ...
>> So for ai, the "upper display limit" is the HOPR field?
>> Yes for the VAL fiels, No for the HHSV fields:
>> It's enumerated, ai.HHSV has values NO_ALARM, MINOR, MAJOR, INVALID
>> and display limits could be NO_ALARSM and INVALID.
>> I don't know what record fields are used for display limits etc.
>> when you attach a channel to e.g. the HIHI field,
>> you want e.g. control limits that allow for putting up
>> a slider that's useful for adjusting the HIHI field.
>> Read the record ref manual of the EPICS base sources
>> if you have to know what e.g. the high/low display limits
>> are for each field.
>
>It also depends on the request type. If the request's base type is
>DBR_ENUM (and this is the default "native" type for DBF_MENU fields like
>HHSV), there is no such attribute "display limits" or "alarm limits" for
>the corresponding _GR_ and _CTRL_ requests. So the questions appears
>only if the value is requested as e.g. DBR_GR_LONG and a reasonable
>choice for e.g. HHSV field would indeed be NO_ALARM as lower and INVALID
>as upper limit.
>
>Unfortunately, the EPICS runtime database does not do so. Instead, these
>attributes field are set to 0 in case of a menu field.
Thanks for pointing this out, Ben.
The point remains:
There is a changing mapping between channel access channel properties
and record fields.
The CAS library is much more flexible than an EPICS IOC,
e.g. you could change the type of your channel's value
and invent new events.
Clients and users, on the other hand, are likely to expect
the strict IOC behavior. If e.g. channel "fred" reports units,
the assumptions is that "fed.EGU" can be accessed to view/change the units.
Similar: high display limits = HOPR, ...
I understand that Ben wrote another layer on top of the standard CAS lib.
which provides "Process Variables" that follow the IOC pattern:
Not only can you serve the full DBR_CTRL_xxx info, you can also access
them via the meanwhile well known record field names.
Purists would argue that is was never meant to be that way,
you shouldn't expect to find "HOPR" for high display limits,
and the next version of CA is likely to help by allowing you to
browse the supported properties of a PV, add new properties etc.,
but meanwhile I guess it's a good idea to mimic an IOC.
Thanks,
-Kay
- References:
- Re: portable ca server Kay-Uwe Kasemir
- Re: portable ca server Benjamin Franksen
- Navigate by Date:
- Prev:
Re: portable ca server Benjamin Franksen
- Next:
bug report Jeff Hill
- 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: portable ca server Benjamin Franksen
- Next:
bug report Jeff Hill
- 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
|