Hi Dirk,
Thanks for the detailed information here; you were correct that this is
2 hex strings each 32-bits long. Using the %x format did the trick for me;
although I swear I tried that already but perhaps using a longin record
which as Mark pointed out does not give me an unsigned integer.
Because these numbers represent bit-wise interlocks I like Stephanie's idea
of using an aSub record ... just seems simpler to parse the bits this way
rather than trying to use database records.
Many thanks to all that replied ... the end result is that I used this
protocol:
get_ilock {
out "din/r";
in "%(\$1InterlockWords.A)x ",
"%(\$1InterlockWords.B)x";
ExtraInput = Ignore;
}
Where the records are aSub records and was able to print the values to the
console from my subroutine as expected.
Thanks,
Marty
Dirk Zimoch wrote:
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
- References:
- streamDevice 32-bit hex value read problem Martin L. Smith
- Re: streamDevice 32-bit hex value read problem Dirk Zimoch
- Navigate by Date:
- Prev:
Re: question of Hytec 8516 added in synApps-5.3 jim.chen
- Next:
archive data server James F Ross
- 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
- Navigate by Thread:
- Prev:
Re: streamDevice 32-bit hex value read problem Dirk Zimoch
- Next:
Re: strange EPICS glitch Eric Norum
- 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
|