Hi,
I was able to reproduce the problem with SCAN=I/O Intr on asynInt32 arrays crashing. I have found and fixed the problem.
Here is the patch:
corvette:modbus/modbusApp/src>svn diff -r14638:14653 drvModbusAsyn.c
Index: drvModbusAsyn.c
===================================================================
--- drvModbusAsyn.c (revision 14638)
+++ drvModbusAsyn.c (revision 14653)
@@ -1371,8 +1371,9 @@
break;
}
/* Need to copy data to epicsInt32 buffer for callback */
+ pasynManager->getAddr(pInt32Array->pasynUser,&offset);
for (i=0; i<pPlc->modbusLength; i++) {
- status = readPlcInt(pPlc, offset,&int32Data[i]);
+ status = readPlcInt(pPlc, offset+i,&int32Data[i]);
}
asynPrint(pPlc->pasynUserTrace, ASYN_TRACE_FLOW,
"%s::readPoller, calling client %p"
I am unable to reproduce the problem with writing FLOAT32_LE values. I can write them to the Modbus slave simulator and display the correct floating point value.
These are the lines from my test startup script:
# Word access at Modbus address 0
# Access 60 words as inputs.
# Function code=3
# default data type unsigned integer.
# drvModbusAsynConfigure("portName", "tcpPortName", slaveAddress, modbusFunction, modbusStartAddress, modbusLength, dataType, pollMsec, "plcType")
drvModbusAsynConfigure("A0_In_Word", "sim1", 0, 4, 0, 60, 0, 2000, "Simulator")
# Access 60 words as outputs.
# Either function code=6 (single register) or 16 (multiple registers) can be used, but 16
# is better because it is "atomic" when writing values longer than 16-bits.
# Default data type unsigned integer.
# drvModbusAsynConfigure("portName", "tcpPortName", slaveAddress, modbusFunction, modbusStartAddress, modbusLength, dataType, pollMsec, "plcType")
drvModbusAsynConfigure("A0_Out_Word", "sim1", 0, 16, 100, 10, 7, 1, "Simulator")
These are the lines from the substitutions file:
# These are the A0 inputs done with word access
file "../../db/intarray_in.template" { pattern
{P, R, PORT, OFFSET, DATA_TYPE, NELM, SCAN}
{SIM1:, LI:UINT16, A0_In_Word, 0, UINT16, 46, "I/O Intr"}
}
file "../../db/aoFloat64.template" { pattern
{P, R, PORT, OFFSET, DATA_TYPE, LOPR, HOPR, PREC}
{SIM1:, AO:FLOAT32_LE, A0_Out_Word, 6, FLOAT32_LE, -1e6, 1e6, 3}
}
I have created a new beta release, R2-4beta2. You can get it here via Subversion:
https://subversion.xor.aps.anl.gov/synApps/modbus/tags/R2-4beta2/
Or here via a tar file:
http://cars.uchicago.edu/software/pub/modbusR2-4beta2.tgz
Please let me know if it fixes your crashing problem.
Also, please tell me the actual error with your FLOAT32_LE ao record problem. Are you sure that Modbus offset 5 is correct. That is an odd number, and I would expect the 32-bit floating point registers might be located at even 16-bit word offsets, i.e. either 4 or 6, not 5. Remember, when you specify the offset of the 32-bit floating point value you specify it in units of 16-bit Modbus registers, not in units of 32-bit registers.
Cheers,
Mark
-----Original Message-----
From: haquin [mailto:[email protected]]
Sent: Friday, April 06, 2012 9:47 AM
To: Eric Norum
Cc: tech-talk; Mark Rivers
Subject: Re: Proposed support for additional Modbus data types
Hi,
- I don't understand why the Linux IOC crash is not reproducible ...
so now the behaviour is the same on both Linux and VxWorks:
Data in the waveform are equal to zero if scan is I/O Intr
Data are correct in the waveform if scan is periodic
- I've successfully tested the read INT32_LE function.
I don't manage to write a FLOAT32_LE:
here is my record:
record(ao, "$(EQPT):TstICons") {
field(SCAN, "Passive")
field(DTYP, "asynFloat64")
field(OUT, "@asyn($(EQPT):Write_IConsFLE 0)FLOAT32_LE")
}
here is my drvModbusAsynConfigure:
drvModbusAsynConfigure("AR-GT7-PC3:Write_IConsFLE", "AR-GT7-PC3", 255, 16 , 5 , 2 , 7 , 1 , "InterfaceIocaste")
do you see any incorrect setting ?
Regards
Le 05/04/2012 17:25, Eric Norum a écrit :
On Apr 5, 2012, at 7:19 AM, haquin wrote:
Hi Mark,
I started to test the new release R2-4 of your modbus driver,
1/ I have a regression problem:
in case of "intarray_in" when scan mode is I/O Intr:
Linux IOC crashes with segmentation error message
Could you run this again under GDB and send a stack trace?
VxWorks IOC doesn't crash but data in the waveform are equal to zero
On Linux if I start with the scan mode set to none there is no crash.
What happens if you change the mode to I/O Intr after the IOC has started?
In both cases linux and VxWorks,
if I change the scanning mode to any periodic scan (with a caput in the SCAN field), I do retreive correct data.
here is my drvModbusAsynConfigure
drvModbusAsynConfigure("AR-GT7-PC3:Read_All", "AR-GT7-PC3", 255, 4 , 0 , 46 , 0 , 2000 , "InterfaceIocaste")
here is my waveform:
record(waveform, "$(EQPT):ReceiveModbusTable") {
field(DTYP, "asynInt32ArrayIn")
field(FLNK, "$(EQPT):TrigModbusTableProcessing")
field(INP, "@asyn($(EQPT):Read_All 0)MODBUS_DATA")
field(NELM, "46")
field(FTVL, "LONG")
field(SCAN, "I/O Intr")
}
2/ I have tested the retreival of float32_LE with ai record, this is ok
tomorrow I'll test retreival of int32 and also he writting.
best regards.