Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Thu, 3 Dec 2015 02:47:41 +0000

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:

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System