Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System