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: Jeong Han Lee <citadel.lee@gmail.com>
To: Andrew Johnson <anj@aps.anl.gov>
Cc: tech-talk <tech-talk@aps.anl.gov>
Date: Mon, 24 Apr 2017 22:13:07 +0200
Hi Andrew,

  Thank you for the explanation. I've agreed that it is not important
thing to fix.

  I will try to do if I have some peaceful time.

  Thanks,
   Han


On Mon, Apr 24, 2017 at 9:43 PM, Andrew Johnson <anj@aps.anl.gov> wrote:
> 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

References:
Data types in monitor function Jeong Han Lee
Re: Data types in monitor function Andrew Johnson

Navigate by Date:
Prev: Re: Data types in monitor function Andrew Johnson
Next: Re: EPICS Archiver Appliance does not transfer PVs to "Being archived" Shankar, Murali
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 Andrew Johnson
Next: CSS Service Panel gennaro.tortone@na.infn.it
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 ·