EPICS Home

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: Mark Rivers <rivers@cars.uchicago.edu>
To: "'Eric Norum'" <wenorum@lbl.gov>, haquin <haquin@ganil.fr>
Cc: tech-talk Talk <tech-talk@aps.anl.gov>
Date: Fri, 6 Apr 2012 16:26:38 +0000
Hi Eric,

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

The output is record is not I/O Intr scanned, it is Passive.  The part of his message relating to I/O Intr scanning is for his input waveform record, shown in a previous message.

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

No, this is not correct.  This is an output Modbus operation (function code=16, write multiple registers). A non-zero poll value just means that the driver should do one initial readback so that the output record matches the hardware at iocInit.  The actual value of the poll time is irrelevant.

Mark


-----Original Message-----
From: Eric Norum [mailto:wenorum@lbl.gov] 
Sent: Friday, April 06, 2012 10:34 AM
To: haquin
Cc: tech-talk Talk; Mark Rivers
Subject: Re: Proposed support for additional Modbus data types

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



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 Eric Norum

Navigate by Date:
Prev: Re: Proposed support for additional Modbus data types Eric Norum
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 Eric Norum
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