EPICS Controls 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  2015  <20162017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: error return from ao device support
From: Andrew Johnson <[email protected]>
To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>
Date: Fri, 25 Mar 2016 12:08:38 -0500
Hi Steve,

On 03/25/2016 01:38 AM, [email protected] wrote:
> It seems to me that when ao device support returns error to record
> support (for instance when the write to the hardware failed) STAT and
> SEVR get put to NO_ALARM anyway!  so applications have no way to know
> the write failed.   Is this a bug or feature?

Where did you read that device support can return an error status like
that? Any such documentation is wrong and I'd like to fix it. If device
support needs to flag an alarm it is supposed to put the record into
alarm state itself by calling
    recGblSetSevr(prec, stat, sevr);

> When ai device support returns error, STAT and SEVR  indicate an
> error.
> 
> I am using 3.14.12.2

I don't see any difference between the way the ai and ao records handle
return status values from the read_ai() / write_ao() support routines,
and I certainly don't see code to do what you're describing. However if
an ai device has never actually returned a value the UDF field will
still be set so there will be a UDF_ALARM. UDF just means that the value
in the VAL field is invalid and should not be used (it also gets set
when VAL contains a NaN).

Any error status from the device support read/write routine is passed
back up to the IOC by process(), but with the exception of the don't
convert behaviour from input records the status doesn't really mean or
do anything. It can make it back to a CA client as an exception which
could confuse your users, so the support routine should probably only
ever return 0 (or 2 for input record types).

HTH,

- Andrew

-- 
There are only two hard problems in distributed systems:
  2. Exactly-once delivery
  1. Guaranteed order of messages
  2. Exactly-once delivery
 -- Mathias Verraes

Replies:
Re: error return from ao device support [email protected]

Navigate by Date:
Prev: RE: Job Posting - Applications/Controls Engineer (I-6) / Advanced Applications/Controls Engineer (I-7) - 24 month term - Brookhaven National Laboratory Esposito, Peter J
Next: Re: error return from ao device support [email protected]
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Job Posting - Applications/Controls Engineer (I-6) / Advanced Applications/Controls Engineer (I-7) - 24 month term - Brookhaven National Laboratory Esposito, Peter J
Next: Re: error return from ao device support [email protected]
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 15 Jul 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·