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.
begin:vcard
fn:Christophe Haquin
n:Haquin;Christophe
email;internet:[email protected]
tel;work:02 31 45 46 61
x-mozilla-html:FALSE
version:2.1
end:vcard
- Replies:
- RE: Proposed support for additional Modbus data types Mark Rivers
- Re: Proposed support for additional Modbus data types Eric Norum
- RE: Proposed support for additional Modbus data types Mark Rivers
- 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
- Navigate by Date:
- Prev:
RE: a question about sequencer Mark Rivers
- Next:
RE: Proposed support for additional Modbus data types Mark Rivers
- 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 Mark Rivers
- 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
|