Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 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
<== Date ==> <== Thread ==>

Subject: Re: Data types in monitor function
From: Andrew Johnson <anj@aps.anl.gov>
To: <tech-talk@aps.anl.gov>
Date: Mon, 24 Apr 2017 14:43:49 -0500
Hi Han,

On 04/24/2017 07:27 AM, Jeong Han Lee wrote:
>   I am wondering the mixed data types in monitor function in
> most_of_Record.c. For example,  static void monitor(aiRecord *prec).
> 
>   recGblResetAlarms function returns epicsUint16 (unsigned short) and the
> returned value is used in different way according to its record, and
> pass it as argument of db_post_events function with mixed data type.
> 
>   All of them mixed data types are larger than its epicsUnit16, so no
> problems I saw.
> 
>   Is it just due to "history of Data types evolution" in many difference
> records? If so, do we have any intention to keep the same data type in
> entire (at least monitor function) EPICS layer? If any help is needed, I
> can work on them.

The value returned by recGblResetAlarms and accepted by db_post_events
is a bitmap which tells the CA server which class of monitor events to
send with this update. The individual bit values are defined in the CA
header caeventmask.h as DBE_xxx macros and these values are used in the
CA network protocol. Currently only the lowest 4 bits are used, so all
values appear in the range 0..15.

Adding additional bits would involve quite a lot of work; in addition to
modifying the IOC core and/or all the record types it also needs changes
to the CA client code and both CA servers (RSRV and CAS) in Base, in
addition to updates to the CA Gateway. I think it unlikely that we would
add many more events, if any.

The differences between the individual record types is certainly
historical, because there were many people involved in creating the
standard set of types that come with Base. There are various things that
we have cleaned up in the record type code over the years, but this one
isn't something that we have bothered with. If you wanted to send us
patches to unify the code we would be happy for the help, but I don't
see this as being a particularly important thing to fix.

HTH,

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Replies:
Re: Data types in monitor function Jeong Han Lee
References:
Data types in monitor function Jeong Han Lee

Navigate by Date:
Prev: Re: EPICS Archiver Appliance does not transfer PVs to "Being archived" Michael Davidsaver
Next: Re: Data types in monitor function Jeong Han Lee
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
Navigate by Thread:
Prev: Re: Data types in monitor function Jeong Han Lee
Next: Re: Data types in monitor function Jeong Han Lee
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
ANJ, 24 Apr 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·