Re: print all information about a PV including units

["Johnson, Andrew N. via Tech-talk" <tech-talk@aps.anl.gov>]

Hi Rachid,

On 2/20/19 12:29 PM, rachid ayad wrote:

Now it works with the -d option:

***************

caget -d DBR_CTRL_DOUBLE BMLXRM:BEAM:SIGMAYatIP

BMLXRM:BEAM:SIGMAYatIP
    Native data type: DBF_DOUBLE
    Request type:     DBR_CTRL_DOUBLE
    Element count:    1
    Value:            0
    Status:           UDF
    Severity:         INVALID
    Units:            nm
    Precision:        10
    Lo disp limit:    0
    Hi disp limit:    0
    Lo alarm limit:   nan
    Lo warn limit:    nan
    Hi warn limit:    nan
    Hi alarm limit:   nan
    Lo ctrl limit:    0
    Hi ctrl limit:    0
******************

Thank you it works and I have what I wanted. For the capr perl script and to install new base version for now we will run soon so is better to not change things as they are working well. But will test it separately

Just one question: You notice the caget and cainfo command prints that Native data type is DBF_DOUBLE and Request type is  DBR_CTRL_DOUBLE so maybe is make sense to ask the native data type DBF_DOUBLE not DBR one?

I'm not sure whether I completely understand what you're asking, but I will explain how the native and request types differ:

The native type is the basic data type of the CA channel's value, one of these possible type names:

/* database field types */
#define DBF_STRING  0
#define DBF_SHORT   1
#define DBF_FLOAT   2
#define DBF_ENUM    3
#define DBF_CHAR    4
#define DBF_LONG    5
#define DBF_DOUBLE  6

The above is from the include/db_access.h header file; the 'DBF' part of the name is short for DataBase Field, and it's used to indicate the type of the field stored in the IOC record.

The CA protocol lets a client program ask for more information about a channel than just its value though, and that's what the 'DBR' types are for; the 'DBR' part is short for DataBase Request. These request types are shown as the list of type names for the -d option to caget. There are DBR versions of all the basic DBF types (whose numeric values are actually identical inside the code), but many more DBR types because of all the extra metadata types we provide.

Confusingly, inside the IOC itself we actually support a different set of field types, and the DBF type-names were re-used with different values and unsigned versions added too. Thus there is actually a larger set of native data types that the IOC can store in record fields, but they get translated into the above set when used by Channel Access.

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