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  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: RE: asynPortDriver callbacks to I/O Intr, how to propagate an error?
From: Mark Rivers <rivers@cars.uchicago.edu>
To: Angus Gratton <angus.gratton@anu.edu.au>, tech-talk <tech-talk@aps.anl.gov>
Date: Wed, 2 May 2012 02:20:51 +0000
Folks,

This request from Angus from about a year ago has come up several times on tech-talk. The problem is that input records with SCAN=I/O Intr did not have a way of having their STAT and SEVR set to indicate a problem with the underlying asyn driver.

I have finally come up with a clean solution to this problem. The solution is for drivers to set the pasynUser->auxStatus field before they do the callbacks to device support. That field in the pasynUser structure is set to 0 (asynSuccess) when the asynUser structure is created, and it is not currently used for any other purpose in the asyn module. This means that using that field for status in callbacks should not break any existing drivers or device support.

I have modified the standard asyn device support so that input records with SCAN=I/O Intr get their status and severity from the pasynUser->auxStatus field.  If that field is not asynSuccess then the record is set to STAT=READ, SEVR=INVALID.

I have added support in asynPortDriver for passing status information to clients in callbacks. Each parameter in the parameter library now has an associated asynStatus variable. New functions setParamStatus() and getParamStatus() are provided to access this variable. If setParamStatus(paramIndex, asynError) is called then callParamCallbacks() will cause any input records with SCAN=I/O Intr to go into alarm state.

I've created a new asyn test application,  asyn/testErrorsApp, which tests this new feature for all interfaces and all records supported by standard asyn device support. It uses a driver that is based on asynPortDriver.

The release notes have been updated.

All changes are committed to SVN.

https://svn.aps.anl.gov/epics/asyn/trunk/


The EPICS modbus application has also been updated to use this new feature.  If a Modbus device has communication errors then all input records with SCAN=I/O Intr will go into INVALID alarm.  Those changes are also committed to SVN.

https://subversion.xor.aps.anl.gov/synApps/modbus/trunk/

I would appreciate feedback from anyone who can test these before I release asyn R4-19 and modbus R2-4.

Cheers,
Mark

________________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Angus Gratton [angus.gratton@anu.edu.au]
Sent: Tuesday, May 10, 2011 7:59 PM
To: tech-talk
Subject: asynPortDriver callbacks to I/O Intr, how to propagate an error?

I have some asynPortDriver-derived driver classes for various pieces of
hardware, most of which are updated when data changes in a DMA read (ie
the background monitoring thread calls setIntegerParam() then calls
callParamCallbacks())

The records are all using I/O Intr so they only scan when required.

Sometimes the DMA read indicates that a piece of hardware has gone
offline. In this case, I'd like to have records using that port scanned
and updated to INVALID severity, and also see an error logged on the
console.

If was using periodic scanning, I believe I could override readInt32()
or equivalent to return asynError status. However, if I want to keep
using I/O Intr then I can't see any way to do this, either with
asynPortDriver or with asyn.

What I'm imagining would help me is a method with a name like
setParamErrorFlag(), that I could call before callParamCallbacks() and
that would propagate the error state back to the record. I'm still very
much an asyn newbie though, so maybe I'm looking at this the wrong way.

Thanks in advance for any tips. If this feature doesn't exist and might
be useful, I'm happy to have a shot at implementing it with a view to
submitting a patch.

- Angus



--
Angus Gratton
Computer Control Specialist
Department of Nuclear Physics
Australian National University

Ph: +61 2 6125 2096



Replies:
Re: asynPortDriver callbacks to I/O Intr, how to propagate an error? Eric Norum

Navigate by Date:
Prev: Re: iocshCmd, redirection, and function pointers Ernest L. Williams Jr.
Next: Re: asynPortDriver callbacks to I/O Intr, how to propagate an error? Eric Norum
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: OK to make function variable in registryFunction.c static? Andrew Johnson
Next: Re: asynPortDriver callbacks to I/O Intr, how to propagate an error? Eric Norum
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·