Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 11 Aug 2016 12:14:14 -0500

Hello Kay,

On 08/11/2016 10:58 AM, Kasemir, Kay wrote:
> 
> 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{
...
>         char            units[MAX_UNITS_SIZE];  /* units of value */
...
> };
> 
> 
> Does anybody remember the reasoning for this?

Old-style db_access (i.e. CA structures) vs newer dbAccess (internal IOC
API with better flexibility). From the newer dbAccessDefs.h:

> #define DB_UNITS_SIZE   16
> #define DBRunits \
> 	char		units[DB_UNITS_SIZE];	/* units	*/

This is similar to the issue that by using the dbAccess API the IOC can
handle enums with up to 30 choices and choice strings (DB_MAX_CHOICES
defined in dbDefs.h), but CA never switched to the new API and can only
transport 16 choice strings, so it can't transport all the STAT menu
strings for example.

> Would it make sense to shorten the EGU field length in records?

I would rather leave it at 16, since we now have pvAccess which *can*
access and transport the wider string.

> Or lengthen MAX_UNITS_SIZE?

That would require changes to the on-the-wire CA protocol and could
break CA client applications.

- 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System