RE: asynPortDriver callbacks to I/O Intr, how to propagate an error?

["Mark Rivers" <rivers@cars.uchicago.edu>]

Hi Angus,

The fact that one cannot pass an error status to device support via the callbacks has come up before.

Back in 2007 I committed a change to add an extra status argument to the callback functions, but a week later I backed out of it because it would break too many existing drivers.

Back then we decided to instead use the "asyn exception" mechanism as the way for drivers to report problems back to device support.  Device support would register an exception callback handler, and that would put the record into alarm status.  I think that could probably be used for output records as well, so they can go into alarm when the driver detects a problem even if they are not periodically processing.

Currently the asynException interface is:

typedef enum {
    asynExceptionConnect,asynExceptionEnable,asynExceptionAutoConnect,
    asynExceptionTraceMask,asynExceptionTraceIOMask,
    asynExceptionTraceFile,asynExceptionTraceIOTruncateSize
} asynException;


typedef void (*exceptionCallback)(asynUser *pasynUser,asynException exception);

typedef struct asynManager {
...

    asynStatus (*exceptionCallbackAdd)(asynUser *pasynUser,
                                       exceptionCallback callback);
    asynStatus (*exceptionCallbackRemove)(asynUser *pasynUser);
    asynStatus (*exceptionConnect)(asynUser *pasynUser);
    asynStatus (*exceptionDisconnect)(asynUser *pasynUser);
    asynStatus (*enable)(asynUser *pasynUser,int yesNo);
 ...

}

Currently there are 2 exception types that could be used to report such errors: asynExceptionConnect and asynExceptionEnable.  For the type of error you are talking about I think asynExceptionConnect is appropriate.  Your driver would call pasynManager->exceptionDisconnect(pasynUser).  The device support exception handler will get a callback informing it that the device has disconnected.  It would then put the record into alarm.  We could also think about adding another asynException type if we really feel it is needed.

All that is needed is to add that exception handler to the generic asyn device support.  In your driver you call pasynManager->exceptionDisconnect(pasynUser) when the device goes offline and pasynManager->exceptionConnect(pasynUser) when it goes back online.  

I recently had an exchange with Eric Norum about exactly this problem and in going through the 2007 e-mails  I found that I had offered to make those changes to generic asyn device support, but never did.

If you want to take a stab at it that would be great!  Otherwise I'll put it on my list.

Cheers,

Mark

 

________________________________

From: tech-talk-bounces@aps.anl.gov on behalf of Angus Gratton
Sent: Tue 5/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