We are still unable to read negative integers from an Acromag XT1221
analog input module, into the RVAL field of an ai record, via asyn and
modbus. (This module represents analog input values as signed 16 bit
integers.)
As we were advised earlier in this thread (see below), we upgraded to
modbus-2-7 (with EPICS 3.15.2), and use modbusDataType 4, which is
supposed to be (signed) INT16:
drvModbusAsynConfigure("CollimCouch", "AcromagCollimCouch",0,4,0,9,4,100,"AcromagXT1221")
But in our ai record, RVAL still acts like an unsigned integer:
When Vin is +0.003 V we see a small positive integer:
$ caget Iso:GantryCouch:Collimator:Actual.RVAL
Iso:GantryCouch:Collimator:Actual.RVAL 3
$ caget -0b Iso:GantryCouch:Collimator:Actual.RVAL
Iso:GantryCouch:Collimator:Actual.RVAL 111
When Vin is -0.025 V we see a large positive integer:
$ caget Iso:GantryCouch:Collimator:Actual.RVAL
Iso:GantryCouch:Collimator:Actual.RVAL 65484
$ caget -0b Iso:GantryCouch:Collimator:Actual.RVAL
Iso:GantryCouch:Collimator:Actual.RVAL 1111111111010000
This is the same behavior as we see with modbusDataType 0, (unsigned) UINT16.
We believe our upgrade from modbus-2-2 to modbus-2-7 did succeed in
installing the new software - before the upgrade, when we tried
modbusDataType 4, RVAL was always zero. We also inspected the code
in support/modbus-2-7/modbusApp/src/drvModbusAsyn.c and confirmed
it was the same as shown earlier in this thread. In particular:
switch (dataType) {
case dataTypeUInt16:
result = value;
break;
...
case dataTypeInt16:
result = (epicsInt16)value;
break;
BUT now we wonder if this code always has the intended effect -
especially the cast to epicsInt16. In epics/base/include/epicsTypes.h
we find:
typedef short epicsInt16;
But is short always the same as signed short int -?
Does anyone have suggestions for how we can get signed integers
into this RVAL, or how we might investigate this further?
Jon Jacky
PS. On our system in /usr/include/limits.h we find:
/* Minimum and maximum values a `signed short int' can hold. */
# define SHRT_MIN (-32768)
# define SHRT_MAX 32767
/* Maximum value an `unsigned short int' can hold. (Minimum is 0.) */
# define USHRT_MAX 65535
Our system is Debian with Linux kernel 3.2.0-4-686-pae. Our compiler
is gcc 4.7.2.
PPS - modbusDataType 1, INT16SM (sign and magnitude) doesn't work
as we expected either, although it works differently. With Vin
+0.003 V:
$ caget Iso:GantryCouch:Collimator:Actual.RVAL
Iso:GantryCouch:Collimator:Actual.RVAL 7
$ caget -0b Iso:GantryCouch:Collimator:Actual.RVAL
Iso:GantryCouch:Collimator:Actual.RVAL 111
with Vin -0.007 V
$ caget Iso:GantryCouch:Collimator:Actual.RVAL
Iso:GantryCouch:Collimator:Actual.RVAL 32782
$ caget -0b Iso:GantryCouch:Collimator:Actual.RVAL
Iso:GantryCouch:Collimator:Actual.RVAL 1000000000001100
Notice RVAL here is near 2^15 rather than 2^16.
----------------------------------------------------------------------
On Thu, 3 Dec 2015, Mark Rivers wrote:
Hi Jon,
Here is the configure call in st.cmd. The modbusFunction is 4
and the modbusDataType is 0, which (with DTYP asynInt32) should select
16-bit word, in binary twos-complement format:
drvModbusAsynConfigure("CollimCouch", "AcromagCollimCouch",0,4,0,9,0,100,"AcromagXT1221")
Your mistake is the statement that modbusDataType=0 is binary twos-complement.
This is the table from the documentation here http://cars9.uchicago.edu/software/epics/modbusDoc.html:
Supported Modbus data types
modbusDataType value drvUser field Description
0 UINT16 Unsigned 16-bit binary integers
1 INT16SM 16-bit binary integers, sign and magnitude format. In this format bit 15 is the sign bit, and bits 0-14 are the absolute value of the magnitude of the number. This is one of the formats used, for example, by Koyo PLCs for numbers such as ADC conversions.
2 BCD_UNSIGNED Binary coded decimal (BCD), unsigned. This data type is for a 16-bit number consisting of 4 4-bit nibbles, each of which encodes a decimal number from 0-9. A BCD number can thus store numbers from 0 to 9999. Many PLCs store some numbers in BCD format.
3 BCD_SIGNED 4-digit binary coded decimal (BCD), signed. This data type is for a 16-bit number consisting of 3 4-bit nibbles, and one 3-bit nibble. Bit 15 is a sign bit. Signed BCD numbers can hold values from -7999 to +7999. This is one of the formats used by Koyo PLCs for numbers such as ADC conversions.
4 INT16 16-bit signed (2's complement) integers. This data type extends the sign bit when converting to epicsInt32.
5 INT32_LE 32-bit integers, little endian (least significant word at Modbus address N, most significant word at Modbus address N+1)
6 INT32_BE 32-bit integers, big endian (most significant word at Modbus address N, least significant word at Modbus address N+1)
7 FLOAT32_LE 32-bit floating point, little endian (least significant word at Modbus address N, most significant word at Modbus address N+1)
8 FLOAT32_BE 32-bit floating point, big endian (most significant word at Modbus address N, least significant word at Modbus address N+1)
9 FLOAT64_LE 64-bit floating point, little endian (least significant word at Modbus address N, most significant word at Modbus address N+3)
10 FLOAT64_BE 64-bit floating point, big endian (most significant word at Modbus address N, least significant word at Modbus address N+3)
So modbusDataType=0 is UINT16, unsigned 16-bit integer. That explains your problem, you should be using modbusDataType=4 (INT16) and your command line should be:
drvModbusAsynConfigure("CollimCouch", "AcromagCollimCouch",0,4,0,9,4,100,"AcromagXT1221")
Mark
________________________________________
From: [email protected] [[email protected]] on behalf of [email protected] [[email protected]]
Sent: Wednesday, December 02, 2015 6:26 PM
To: [email protected]
Subject: ai RVAL via asyn + modbus: getting unsigned integer
I am reading from an Acromag XT1221 analog input module, into the RVAL
field of an ai record, via asyn and modbus.
This module encodes analog voltages as 16-bit signed integers, but it
appears that EPICS interprets them as unsigned integers when it
reports the RVAL. As the input voltage crosses from a small positive
to a small negative value, RVAL discontinuously jumps from a small
positive integer to a large positive integer. The VAL computed from
RVAL via ESLO and EOFF also jumps discontinuously.
For example when the input voltage is +0.009 V:
$ caget Iso:GantryCouch:Collimator:Actual.RVAL
Iso:GantryCouch:Collimator:Actual.RVAL 17
$ caget -0b Iso:GantryCouch:Collimator:Actual.RVAL
Iso:GantryCouch:Collimator:Actual.RVAL 10110
But when the input voltage is -0.002 V:
$ caget Iso:GantryCouch:Collimator:Actual.RVAL
Iso:GantryCouch:Collimator:Actual.RVAL 65534
$ caget -0b Iso:GantryCouch:Collimator:Actual.RVAL
Iso:GantryCouch:Collimator:Actual.RVAL 1111111111111110
I expected this RVAL to be reported (in decimal) as a small negative
integer, not a large positive integer. (The binary numbers are not
exactly equal to the decimal numbers because the voltage varies
slightly between caget samples). Displaying the record contents with
dpbr (in iocsh) shows the same thing: large positive RVAL with small
negative voltages.
Here is part of the template that generates the ai record:
Here is part of the template that generates the ai record:
record(ai, "$(ROOM="Iso"):$(SUBSYSTEM):$(SETTING):Actual") {
field(DESC, "$(DESC)")
field(SCAN, "I/O Intr")
field(DTYP, "asynInt32")
field(INP, "@asynMask(CollimCouch, $(OFFSET), 16, 1000)MODBUS_DATA")
field(LINR, "SLOPE")
field(ESLO, "$(ESLO=1.0)")
field(EOFF, "$(EOFF=0.0)")
...
}
Here is the configure call in st.cmd. The modbusFunction is 4
and the modbusDataType is 0, which (with DTYP asynInt32) should select
16-bit word, in binary twos-complement format:
drvModbusAsynConfigure("CollimCouch", "AcromagCollimCouch",0,4,0,9,0,100,"AcromagXT1221")
Is there anything I can do to get a signed integer in this RVAL, so
small negative voltages result in small negative integers?
Jon Jacky
- Replies:
- Re: ai RVAL via asyn + modbus: getting unsigned integer Eric Norum
- RE: ai RVAL via asyn + modbus: getting unsigned integer Mark Rivers
- References:
- RE: ai RVAL via asyn + modbus: getting unsigned integer Mark Rivers
- Navigate by Date:
- Prev:
Re: IOC CA client Andrew Johnson
- Next:
Re: ai RVAL via asyn + modbus: getting unsigned integer 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
- Navigate by Thread:
- Prev:
RE: ai RVAL via asyn + modbus: getting unsigned integer Mark Rivers
- Next:
Re: ai RVAL via asyn + modbus: getting unsigned integer 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
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·