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

 

 

 

 

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.