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
- Replies:
- RE: ai RVAL via asyn + modbus: getting unsigned integer jon
- References:
- RE: ai RVAL via asyn + modbus: getting unsigned integer Mark Rivers
- RE: ai RVAL via asyn + modbus: getting unsigned integer jon
- Navigate by Date:
- Prev:
Re: ai RVAL via asyn + modbus: getting unsigned integer Mark Rivers
- Next:
Re: MEDM Extension Make Failed on Ubuntu 15.10 Jeong Han Lee
- 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 jon
- 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
|