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

Subject: RE: asynPortDriver callbacks to I/O Intr, how to propagate an error?
From: Mark Rivers <rivers@cars.uchicago.edu>
To: "'Heesterman, Peter J'" <Peter.Heesterman@ccfe.ac.uk>, "EPICS Tech-Talk (tech-talk@aps.anl.gov)" <tech-talk@aps.anl.gov>
Date: Fri, 30 Oct 2015 18:21:03 +0000

Hi Peter,

 

The behavior change you observe was deliberate and is documented in the asyn R4-27 release notes.

 

********************************

  • Changed error handling when any of the following errors are encountered:
    • pasynManager->queueRequest returns an error
    • The I/O call to the driver (e.g. pasynInt32->read()) returns an error.
    • The interrupt callback function is passed an error code in pasynUser->auxStatus

Previously such errors did correctly set the record alarm status and severity. However, they did not return an error code to the function that called the device support write() or read() function. They also updated the record VAL or RVAL field when there was an error, which they should not. Now these functions return an error code and do not update VAL or RVAL when there is an error.

*********************************

 

If you call setParamStatus with an error code, that results in a callback with pasynUser->auxStatus set to that error code.  In that case the VAL field of the record is no longer set.  This was a request from Ralph Lange, and I think it is the desired behavior.

 

If you also want to set the VAL field to signal a problem then you must now do the following:

 

   setParamStatus(param, ASYN_SUCCESS);  /* If it might previously have been an error code */

   setXXXParam(param, value);

   callParamCallbacks();

   setParamStatus(param, ASYN_ERROR);  /* Or other error */

  callParamCallbacks();

 

Mark

 

 

 

From: Heesterman, Peter J [mailto:Peter.Heesterman@ccfe.ac.uk]
Sent: Friday, October 30, 2015 12:44 PM
To: EPICS Tech-Talk (tech-talk@aps.anl.gov); Mark Rivers
Subject: Re: asynPortDriver callbacks to I/O Intr, how to propagate an error?

 

Hi Mark,

 

I’m sorry to trouble you again, on a different subject.

I refer to http://www.aps.anl.gov/epics/tech-talk/2012/msg00924.php.

 

I’m using  setParamStatus, for an I/O Intr driven ‘Fault’ value, in my application, to signal alarm status.

 

There seems to have been a behaviour change between Asyn 4-26 and Asyn 4-27.

 

When using 4-27, the alarm status on ‘Fault.SEVR’ field is set to INVALID, but the ‘Fault.VAL’ field is not updated with the (non-zero) value that indicates the fault condition.

But if I comment out the setParamStatus call, then Fault.VAL is set to the correct value.

 

Both values were set as expected, while using 4-26.

 

Many thanks,

 

Peter.

 

 

 

 

 

 


References:
Re: asynPortDriver callbacks to I/O Intr, how to propagate an error? Heesterman, Peter J

Navigate by Date:
Prev: Re: Unable to build support modules on Windows, with base 3.15.2 Andrew Johnson
Next: How to update CSS version 3.x to 4.x ? Patard Charles-Henri
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017 
Navigate by Thread:
Prev: Re: asynPortDriver callbacks to I/O Intr, how to propagate an error? Heesterman, Peter J
Next: EPICS Version 4.5 White, Greg
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·