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 2025 | 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 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: streamDevice 32-bit hex value read problem |
From: | Dirk Zimoch <[email protected]> |
To: | "Martin L. Smith" <[email protected]> |
Cc: | [email protected] |
Date: | Tue, 13 Nov 2012 09:49:40 +0100 |
Hi Marty, %R is the floating point raw format. The integer raw format is %r.(Here I assume that you really get binary data, not the hex string "ffffffff ffffffff", which would be a case for %x.)
I am a bit confused, because ffffffff ffffffff is 2 32 bit values or 1 64 bit value.
Stream device can read a 32 bit big endian signed integer with %4r, a 32 bit big endian unsigned integer with %04r, a 32 bit little endian signed integer with %#4r and so on.
On 64 bit machines, StreamDevice can even read 64 bit integers with %8r, but no EPICS record can store them. So you are limited to 32 bit signed or unsigned at the moment.
In case you do not have binary data but hex strings, (and the space in your format suggests that) you should use %x.
Dirk On 12.11.2012 21:21, Martin L. Smith wrote:
I'm trying to read a 32-bit hex value like ffffffff ffffffff using EPICS R3.14.12.2, streamDevice 2-5, and asyn 4-19 on 64-bit Linux OS. When I read these values using the following protocol: get_ilock { out "din"; in "%(\$1FirstInterlockWord.VAL)8R ", "%(\$1SecondInterlockWord.VAL)0R"; ExtraInput = Ignore; } Both records are longin records and no matter if I use the 8R or 0R I always get the same result: ID06ds:FirstInterlockWord 11/12/12 14:03:02.743812335 -2147483648 ID06ds:SecondInterlockWord 11/12/12 14:03:02.743823268 -2147483648 Turns out that this is hex value 80000000 If I use a strngin record I can see that I'm getting the expected data. Is this the largest value that I can read using streamDevice or is there some other way that I should try to read these values? Thanks, Marty