Experimental Physics and Industrial Control System

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: [email protected] 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

References:

asynPortDriver callbacks to I/O Intr, how to propagate an error? Angus Gratton

Navigate by Date:

Prev: RE: Filtering Archive data james.rowland

Next: Re: Disconnected PVs Andrew Johnson

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <2011>  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: asynPortDriver callbacks to I/O Intr, how to propagate an error? Angus Gratton

Next: Calculation in SNL/SEQ liuping

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <2011>  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024