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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: EGU field length vs. Channel Access protocol |
From: | bob dalesio <[email protected]> |
To: | "Kasemir, Kay" <[email protected]> |
Cc: | "Vodopivec, Klemen" <[email protected]>, "[email protected]" <[email protected]> |
Date: | Thu, 11 Aug 2016 12:23:50 -0400 |
Hi:
Klemen found that the EGU field for ai is STRING[16] and he can set an EGU field accordingly:
$ caput BL11A:Det:crocD2:Y1:RateTrigger.EGU "abcdefghijklmnop"
Old : BL11A:Det:crocD2:Y1:RateTrigger.EGU 123456789012345
New : BL11A:Det:crocD2:Y1:RateTrigger.EGU abcdefghijklmno
The channel access protocol, however, only gives us a MAX_UNITS_SIZE of 8 in db_access.h:
#define MAX_UNITS_SIZE 8
/* structure for a control double field */
struct dbr_ctrl_double{
dbr_short_t status; /* status of value */
dbr_short_t severity; /* severity of alarm */
dbr_short_t precision; /* number of decimal places */
dbr_short_t RISC_pad0; /* RISC alignment */
char units[MAX_UNITS_SIZE]; /* units of value */
dbr_double_t upper_disp_limit; /* upper limit of graph */
dbr_double_t lower_disp_limit; /* lower limit of graph */
dbr_double_t upper_alarm_limit;
dbr_double_t upper_warning_limit;
dbr_double_t lower_warning_limit;
dbr_double_t lower_alarm_limit;
dbr_double_t upper_ctrl_limit; /* upper control limit */
dbr_double_t lower_ctrl_limit; /* lower control limit */
dbr_double_t value; /* current value */
};
Does anybody remember the reasoning for this?
Would it make sense to shorten the EGU field length in records?
Or lengthen MAX_UNITS_SIZE?
Or was this done in anticipation of 2-byte characters for units ;-) ?
-Kay