Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Sat, 12 Dec 2015 13:44:49 +0000

Hi Jon,

In your database for the ai record what is the drvInfo field in the INP link? Is it still MODBUS_DATA? If so, that should be fine.

Please send the output of the following command:

asynReport(1, "CollimCouch")

This is the relevant code that should be being called each time it reads a value:

asynStatus readPlcInt(modbusStr_t *pPlc, int offset, epicsInt32 *output)
{
    epicsUInt16 value = pPlc->data[offset];
    modbusDataType_t dataType = pPlc->dataType[offset];
    epicsInt32 result=0;
...
    switch (dataType) {
        case dataTypeInt16:
        result = (epicsInt16)value;
        break;
...
    *output = result;
    return status;
}

So there is an epicsUInt16 (value) that should be being cast to an epicsInt16 and then converted to an epicsInt32 (result), which is returned.

Here is a little C program that tests those operations:
**********************************************
#include <stdio.h>
#include <epicsTypes.h>

main(int argc, char **argv)
{
    epicsInt32 result;
    epicsUInt16 data=0xFFFF;

    result = data;
    printf("Data with no cast=%d (0x%x)\n", result, result);
    result = (epicsInt16)data;
    printf("Data with cast to epicsInt16=%d (0x%x)\n", result, result);
    return 0;
}
**********************************************

This program creates an epicsUInt16 value, sets it to 0xFFFF. It then copies that value to an epicsInt32 with and without a cast to epicsInt16 and prints the results both in decimal and in hex.

corvette:modbus/modbusApp/src>../../bin/linux-x86_64/testInt16
Data with no cast=65535 (0xffff)
Data with cast to epicsInt16=-1 (0xffffffff)

The results are as I expect, the epicsInt32 is 65535 with no cast, and -1 with a cast. This is exactly what the readPlcInt function above is doing.

You could add the following printf statement to drvModbusAsyn.c::readPlcInt and see what the output is for that value.

        case dataTypeInt16:
        result = (epicsInt16)value;
printf("readPlcInt, offset=%d, value=0x%x, result=%d (0x%x)\n", offset, value, result, result);
        break;

Mark

________________________________________
From: [email protected] [[email protected]]
Sent: Friday, December 11, 2015 6:50 PM
To: Mark Rivers
Cc: [email protected]
Subject: RE: ai RVAL via asyn + modbus: getting unsigned integer

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
>
>
>
>
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System