Hi,
I believe the error messages you are getting at init are because you have set noAutoConnect flag=1 in drvAsynIPPortConfigure:
drvAsynIPPortConfigure("AR-GT7-PC3","172.16.150.13:502",0,1,1)
In modbus versions prior to R2-1 noAutoConnect=1 was the recommended setting. However, beginning in R2-1 automatic connection was fixed, and so it should be used. You should change this to:
drvAsynIPPortConfigure("AR-GT7-PC3","172.16.150.13:502",0,0,1)
The errors at exit are probably because the underlying ports have been closed before the modbus poller is disabled. I will look into this, but it is not serious.
Mark
-----Original Message-----
From: haquin [mailto:[email protected]]
Sent: Wednesday, April 11, 2012 8:28 AM
To: Mark Rivers
Cc: Eric Norum; tech-talk
Subject: Re: Proposed support for additional Modbus data types
Hi Mark,
I have tested your R2-4beta2 version, the problem with SCAN=I/O Intr on asynInt32 arrays is solved.
The FLOAT32_LE writing with ao was in fact working fine, I forgot to issue a command to trig the consign update ...
everythings works fine
However, I have those messages at IOC init and exit and I don't know what to think about them :
#-----------------------------------------------------------------
drvAsynIPPortConfigure("AR-GT7-PC3","172.16.150.13:502",0,1,1)
modbusInterposeConfig("AR-GT7-PC3",0,5000)
drvModbusAsynConfigure("AR-GT7-PC3:Read_All", "AR-GT7-PC3", 255, 4 , 0 , 46 , 0 , 200 , "InterfaceIocaste")
drvModbusAsynConfigure("AR-GT7-PC3:ReadFLE", "AR-GT7-PC3", 255, 4 , 9 , 2 , 0 , 200 , "InterfaceIocaste")
drvModbusAsynConfigure("AR-GT7-PC3:Write_IConsFLE", "AR-GT7-PC3", 255, 16 , 5 , 2 , 0 , 1 , "InterfaceIocaste")
2012/04/11 15:04:00.827 drvModbusAsyn::doModbusIO port AR-GT7-PC3:Read_All is disconnected
2012/04/11 15:04:00.828 drvModbusAsyn::doModbusIO port AR-GT7-PC3:ReadFLE is disconnected
2012/04/11 15:04:00.828 drvModbusAsyn::doModbusIO port AR-GT7-PC3:Write_IConsFLE is disconnected
drvModbusAsynConfigure("AR-GT7-PC3:Write_IRampFLE", "AR-GT7-PC3", 255, 16 , 1 , 2 , 0 , 1 , "InterfaceIocaste")
drvModbusAsynConfigure("AR-GT7-PC3:Write_Cmd", "AR-GT7-PC3", 255, 6 , 0 , 1 , 0 , 1 , "InterfaceIocaste")
#-----------------------------------------------------------------
iocAlimHzrLx > exit
2012/04/11 15:04:41.098 drvModbusAsyn::doModbusIO port AR-GT7-PC3:ReadFLE error calling writeRead,
error=172.16.150.13:502 disconnected:, nwrite=0/6, nread=0
2012/04/11 15:04:41.114 drvModbusAsyn::doModbusIO port AR-GT7-PC3:Read_All error calling writeRead,
error=172.16.150.13:502 disconnected:, nwrite=0/6, nread=0
2012/04/11 15:04:41.300 drvModbusAsyn::doModbusIO port AR-GT7-PC3:ReadFLE has I/O error
2012/04/11 15:04:41.315 drvModbusAsyn::doModbusIO port AR-GT7-PC3:Read_All has I/O error
Le 06/04/2012 22:14, Mark Rivers a écrit :
> 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.
>>>
- References:
- Proposed support for additional Modbus data types Mark Rivers
- RE: Proposed support for additional Modbus data types Mark Rivers
- Re: Proposed support for additional Modbus data types haquin
- RE: Proposed support for additional Modbus data types Mark Rivers
- Re: Proposed support for additional Modbus data types haquin
- Re: Proposed support for additional Modbus data types Eric Norum
- Re: Proposed support for additional Modbus data types haquin
- RE: Proposed support for additional Modbus data types Mark Rivers
- Re: Proposed support for additional Modbus data types haquin
- Navigate by Date:
- Prev:
Re: Proposed support for additional Modbus data types haquin
- Next:
RE: What is void* puser in ca_create_channel Hill, Jeffrey O
- 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: Proposed support for additional Modbus data types haquin
- Next:
Re: Proposed support for additional Modbus data types Eric Norum
- 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
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·