The problem is that both, ai.RVAL and longin.VAL are of type "LONG"
which is a 32 bit signed integer. Even when StreamDevice puts a 32 bit
unsigned value there, the record will interpret it as signed. Thus
neither ai.RVAL nor longin.VAL are able to store the value 2283351134.
I am currently working on StreamDevice 2.8 and I will try to fix that at
least for ai.VAL. I have to work around the default value conversion in
the record for that...
Dirk
On 02.08.2018 21:57, Martin L. Smith wrote:
Hi,
I'm being sent a ULONG such as 2283351134 (base 10) and asyn shows
me in hex the number coming across as 5e 2c 19 88 and it should be
88 19 2c 5e so the order is reversed when the number is sent to the
IOC.
When I use the format converter %04r
I get the number 1579948424 (base 10) which is 5e 2c 19 88
When I use the format converter %#4r
I get the number -2011616162 which I think would be the correct
number if it was unsigned.
What I really want to do is something like a format converter %#04r
but combining the # and the 0 flags doesn't seem to do what I want.
I need the value to be unsigned AND 32 bits byte order swapped.
Has anyone else run across this issue and if so how did you make it
work?
We are going to try sending a char array instead and see if that helps.
Thanks,
Marty
- References:
- streamDevice 32-Bit ULONG endianess Martin L. Smith
- Navigate by Date:
- Prev:
Re: Delta Tau motor control problem [email protected]
- Next:
DBE_PROPERTY and Gateway Dominic Oram - UKRI STFC
- 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:
streamDevice 32-Bit ULONG endianess Martin L. Smith
- Next:
Re: streamDevice 32-Bit ULONG endianess Dirk Zimoch
- 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
|