Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Mon, 27 Aug 2001 13:36:24 -0600

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System