On 6/8/20 4:18 PM, Michael Davidsaver wrote:
> ...
> 1. Add alarm message and time tag to dbCommon in Base
>
> Not directly related to DBR_VFIELD, but adds an alarm
> message string, and time tag a la. PVA. Also, adds
> a 'utag' server side filter which can apply a bitmask
> to the time tag.
>
> https://github.com/epics-base/epics-base/pull/71
Continuing the discussion/review of this multi-part series,
I'd like to go into detail about the first part or the first PR.
The added ability to provide a string describing alarms.
From the prospective of a device support author,
this interface can be summarized as:
> int recGblSetSevrMsg(void *precord, epicsEnum16 new_stat,
> epicsEnum16 new_sevr,
> const char *msg)
Were currently a device support might have:
> if(!connected)
> recGblSetSevr(prec, READ_ALARM, INVALID_ALARM);
More information could be provided with:
> if(!connected)
> recGblSetSevrMsg(prec, READ_ALARM, INVALID_ALARM, "No Conn");
Practically, this is a way to disambiguate status codes like READ_ALARM
or COMM_ALARM which tend to have multiple meanings.
From the prospective of a user, this message will appear in
a new AMSG field. It can be accessed like any other record string field.
An additional benefit is that with QSRV it will appear as part of
the PVA alarm meta-data. aka. the 'alarm.message' structure field.
The PR adds a couple of internal usages of recGblSetSevrMsg().
Probably the most interesting is to the link code so that
when a link operation signals an alarm, the link field name
is given as the alarm message.
So eg. it can be seen at a glance that INPE of a calcRecord
has set a LINK_ALARM.
Open questions:
* Is a printf()-like form of recGblSetSevrMsg() needed?
(currently message length is limited to 40 characters)
* Does struct lset need changing? (and how?)
Needed for eg. MSS to copy message string
- References:
- DBR_VFIELD and complex field types Michael Davidsaver via Core-talk
- Navigate by Date:
- Prev:
Re: [Merge] ~dirk.zimoch/epics-base:fix_zero_size_arrays into epics-base:7.0 Dirk Zimoch via Core-talk
- Next:
Build failed: EPICS Base 7 base-7.0-40 AppVeyor via Core-talk
- Index:
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: DBR_VFIELD and complex field types Johnson, Andrew N. via Core-talk
- Next:
Build failed: epics-base base-vfield-530 AppVeyor via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
|