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: print all information about a PV including units |
From: | rachid ayad via Tech-talk <[email protected]> |
To: | "Johnson, Andrew N." <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Thu, 21 Feb 2019 04:12:17 +0900 |
Hi Rachid,
On 2/20/19 12:29 PM, rachid ayad wrote:
I'm not sure whether I completely understand what you're asking, but I will explain how the native and request types differ: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?
The native type is the basic data type of the CA channel's value, one of these possible type names:
/* database field types */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.
#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 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
------------------------------
هذه الرسالة و مرفقاتها (إن وجدت) تمثل وثيقة سرية قد تحتوي على معلومات تتمتع بحماية وحصانة قانونية . إذا لم تكن الشخص المعني بهذه الرسالة يجب عليك تنبيه المُرسل بخطأ وصولها إليك، و حذف الرسالة و مرفقاتها (إن وجدت) من الحاسب الآلي الخاص بك. ولا يجوز لك نسخ هذه الرسالة أو مرفقاتها (إن وجدت) أو أي جزئ منها، أو البوح بمحتوياتها لأي شخص أو استعمالها لأي غرض . علماً بأن الإفادات و الآراء التي تحويها هذه الرسالة تعبر فقط عن رأي المُرسل و ليس بالضرورة رأي جامعة تبوك . ولا تتحمل جامعة تبوك أي مسئولية عن الأضرار الناتجة عن أي فيروسات قد يحملها هذ البريد.
This message and its attachment, if any, are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender immediately and delete this message and its attachment , if any, from your system. You should not copy this message or disclose its contents to any other person or use it for any purpose. Statements and opinions expressed in this e-mail are those of the sender, and do not necessarily reflect those of University of Tabuk. University of Tabuk Accepts no liability for any damage caused by any virus transmitted by this email.