At 07:21 PM 8/25/2001, you wrote:
>I noticed that my ca server does not respond properly when a
>ca_get_callback is called using DBR_GR_??? or DBR_CTRL_???, i.e. I don't
>send warning and alarm limits back properly. Instead, lower
>warning and alarm limits are populated by values for lopr.
>Upper limits get hopr. What do I do to fix this behavior?
Hello:
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.
So I wouldn't be sure WHAT to provide in a home-grown
CA server, but as to HOW to provide it:
Your casPV-derived class has a
caStatus read (const casCtx &ctx, gdd &prototype)
method.
The prototype tells you what's requested:
Is it value, display limits,...?
If the client asked for DBR_CTRL_xxx,
the prototype will be a "container" of value, display limits, units,
alarm limits, warning limits, control limits.
base/src/cas/example/simple/exPV.cc has an example of how to handle all these
cases:
1) install a hash-table for dispatching all requests
that you intend to handle:
void exPV::initFT()
{
if (exPV::hasBeenInitialized) {
return;
}
exPV::ft.installReadFunc ("status", &exPV::getStatus);
exPV::ft.installReadFunc ("severity", &exPV::getSeverity);
exPV::ft.installReadFunc ("seconds", &exPV::getSeconds);
exPV::ft.installReadFunc ("nanoseconds", &exPV::getNanoseconds);
exPV::ft.installReadFunc ("precision", &exPV::getPrecision);
exPV::ft.installReadFunc ("graphicHigh", &exPV::getHighLimit);
exPV::ft.installReadFunc ("graphicLow", &exPV::getLowLimit);
exPV::ft.installReadFunc ("controlHigh", &exPV::getHighLimit);
exPV::ft.installReadFunc ("controlLow", &exPV::getLowLimit);
exPV::ft.installReadFunc ("alarmHigh", &exPV::getHighLimit);
exPV::ft.installReadFunc ("alarmLow", &exPV::getLowLimit);
exPV::ft.installReadFunc ("alarmHighWarning", &exPV::getHighLimit);
exPV::ft.installReadFunc ("alarmLowWarning", &exPV::getLowLimit);
exPV::ft.installReadFunc ("units", &exPV::getUnits);
exPV::ft.installReadFunc ("value", &exPV::getValue);
exPV::ft.installReadFunc ("enums", &exPV::getEnums);
exPV::hasBeenInitialized = 1;
}
2) read is now simply
caStatus exPV::read (const casCtx &, gdd &protoIn)
{
return this->ft.read (*this, protoIn);
}
That handles a simple "value" request as well as containers
3) implement all the elementary responses:
caStatus exPV::getValue(gdd &value)
caStatus exPV::getLowLimit(gdd &value)
...
-Kay
- Replies:
- Re: portable ca server Benjamin Franksen
- Navigate by Date:
- Prev:
RE: portable ca server Jeff Hill
- Next:
Re: portable ca server Benjamin Franksen
- 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 john sinclair
- Next:
Re: portable ca server Benjamin Franksen
- 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
|