Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: Proposed support for additional Modbus data types
From: haquin <haquin@ganil.fr>
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: Eric Norum <wenorum@lbl.gov>, tech-talk <tech-talk@aps.anl.gov>
Date: Wed, 11 Apr 2012 15:27:50 +0200
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:haquin@ganil.fr]
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.

begin:vcard
fn:Christophe Haquin
n:Haquin;Christophe
email;internet:haquin@ganil.fr
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
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

Navigate by Date:
Prev: RE: help about labview gui of diamond light source austen.rose
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  <20122013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: RE: Proposed support for additional Modbus data types 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  <20122013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·