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: Eric Norum <wenorum@lbl.gov>
To: haquin <haquin@ganil.fr>
Cc: tech-talk Talk <tech-talk@aps.anl.gov>
Date: Fri, 6 Apr 2012 08:34:15 -0700
On Apr 6, 2012, at 7:46 AM, haquin wrote:

> 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")
> }

What does SCAN=I/O Intr mean for output records?  Is that even supported?

> 
> 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 ?

The arguments to drvModbusAsynConfigure are
drvModbusAsynConfigure(portName,		"AR-GT7-PC3:Write_IConsFLE",
                       tcpPortName,					"AR-GT7-PC3"
                       slaveAddress, 				255
                       modbusFunction, 				16
                       modbusStartAddress, 			5
                       modbusLength,				2
                       dataType,					7
                       pollMsec, 					1
                       plcType);						"InterfaceIocaste"


A one millisecond polling interval seems rather short.  Perhaps things simply don't have time to finish processing at that rate.

Records using the new drvUser feature (e.g. the FLOAT32_LE in the OUT field shown above)  can specify the registers as dataType=0 -- this is handy since you can mix integer and floating values in a single I/O block.



-- 
Eric Norum
wenorum@lbl.gov



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

Navigate by Date:
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 
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 ·