Experimental Physics and
Industrial Control System

Eric Norum <[email protected]> · Tue, 1 May 2012 19:58:06 -0700

Rather than simply setting READ/INVALID when auxStatus is non-zero, how about passing the STAT in the upper 16 bits of auxStatus and the SEVR in the lower 16-bits.    We could provide a macro (asynSetAuxStatus(stat,sevr)) to make this easier.

On May 1, 2012, at 7:20 PM, Mark Rivers wrote:

> 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: [email protected] [[email protected]] on behalf of Angus Gratton [[email protected]]
> 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
> 
> 

-- 
Eric Norum
[email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System