Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Mon, 14 Dec 2015 19:56:33 +0000

Hi Jon,

I believe I may have found your problem.  This is from your original post:

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)")
  ...
}

In particular:
  field(DTYP, "asynInt32")
  field(INP, "@asynMask(CollimCouch, $(OFFSET), 16, 1000)MODBUS_DATA")

So you are using asynInt32 device support with the asynMask link syntax.

This is the documentation from for asynInt32 and asynMask from  http://cars9.uchicago.edu/software/epics/modbusDoc.html 

************************************************************
field(INP,"@asynMask(portName,offset,nbits,timeout)drvUser")

The asynMask syntax is used for analog I/O devices, in order to specify the number of bits in the device. This is required for Modbus because the driver only knows that it is returning a 16-bit register, but not the actual number of bits in the device, and hence cannot return meaningful data with asynInt32->getBounds().

nbits>0 for a unipolar device. For example, nbits=12 means unipolar 12-bit device, with a range of 0 to 4095. nbits<0 for a bipolar device. For example, nbits=-12 means bipolar 12-bit device, with a range of -2048 to 2047)
************************************************************

So you have set nbits=16.  But the documentation explains the nbits>0 is for unipolar devices.  Yours is not a unipolar device, it is a bipolar device, so you should be setting nbits=-16.

I believe that will fix your problem.

Mark

________________________________________
From: [email protected] [[email protected]]
Sent: Monday, December 14, 2015 1:22 PM
To: Mark Rivers
Cc: [email protected]
Subject: RE: ai RVAL via asyn + modbus: getting unsigned integer

I did the experiment Mark suggested and found that drvModbusAsyn.c is working as
expected - it returns small negative integers when small negative voltages are applied to the converter.  BUT in those cases RVAL is still reported as a large positive integer.  Details follow:

On Sat, 12 Dec 2015, Mark Rivers wrote:

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

I did that and got these results.  When Vin is a small positive value +0.002 V,
value is a small positive integer and RVAL is a small positive integer:

readPlcInt, offset=0, value=0x1, result=1 (0x1)

dbgf Iso:GantryCouch:Collimator:Actual.RVAL
DBR_LONG:           6         0x6

(the voltage varies slightly between the printf and dbgf outputs)

But when Vin is -0.008 V, value is a small negative integer BUT RVAL is
a large positive integer:

  readPlcInt, offset=0, value=0xfff4, result=-12 (0xfffffff4)

dbgf Iso:GantryCouch:Collimator:Actual.RVAL
DBR_LONG:           65524     0xfff4

So it seems RVAL is handled differently than value.  Is there some way to make
RVAL behave like value?

Jon Jacky

PS - here are answers to Mark's other questions about MODBUS_DATA and asynReport

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

Yes, dbpr reports the INP field is INP:INST_IO @asynMask(CollimCouch, 0, 16, 1000)MODBUS_DATA

> Please send the output of the following command:
>
> asynReport(1, "CollimCouch")

I believe addr 0 is connected to Vin in the output shown above.

epics> asynReport(1, "CollimCouch")
CollimCouch multiDevice:Yes canBlock:Yes autoConnect:Yes
     enabled:Yes connected:Yes numberConnects 1
     nDevices 6 nQueued 0 blocked:No
     asynManagerLock:No synchronousLock:No
     exceptionActive:No exceptionUsers 0 exceptionNotifys 0
     traceMask:0x1 traceIOMask:0x0 traceInfoMask:0x1
     addr 0 autoConnect Yes enabled Yes connected No exceptionActive No
         exceptionActive No exceptionUsers 0 exceptionNotifys 0
         blocked No
         traceMask:0x1 traceIOMask:0x0 traceInfoMask:0x1
     addr 5 autoConnect Yes enabled Yes connected No exceptionActive No
         exceptionActive No exceptionUsers 0 exceptionNotifys 0
         blocked No
         traceMask:0x1 traceIOMask:0x0 traceInfoMask:0x1
     addr 3 autoConnect Yes enabled Yes connected No exceptionActive No
         exceptionActive No exceptionUsers 0 exceptionNotifys 0
         blocked No
         traceMask:0x1 traceIOMask:0x0 traceInfoMask:0x1
     addr 4 autoConnect Yes enabled Yes connected No exceptionActive No
         exceptionActive No exceptionUsers 0 exceptionNotifys 0
         blocked No
         traceMask:0x1 traceIOMask:0x0 traceInfoMask:0x1
     addr 2 autoConnect Yes enabled Yes connected No exceptionActive No
         exceptionActive No exceptionUsers 0 exceptionNotifys 0
         blocked No
         traceMask:0x1 traceIOMask:0x0 traceInfoMask:0x1
     addr 1 autoConnect Yes enabled Yes connected No exceptionActive No
         exceptionActive No exceptionUsers 0 exceptionNotifys 0
         blocked No
         traceMask:0x1 traceIOMask:0x0 traceInfoMask:0x1
modbus port: CollimCouch
     asynOctet server:   AcromagCollimCouch
     modbusSlave:        0
     modbusFunction:     4
     modbusStartAddress: 00
     modbusLength:       011
     plcType:            AcromagXT1221
     I/O errors:         0
     Read OK:            2207
     Write OK:           0
     pollDelay:          0.100000
     Time for last I/O   1 msec
     Max. I/O time:      7 msec
     Time per hist. bin: 1 msec

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System