Hi Andrew,
Yes, I had already found some old code of mine with recGlbSetSevr, and it worked fine, which is why I cancelled my post to tech-talk.
However, application developers guide does not mention this under the device support description (unless I missed it) perhaps it should be there.
Are you saying that when an error is detected in dev support it should still return ok????
I think record support returns -1 when it detects an error, if so should dev support not do the same?
anyway, as I said, no longer a problem for me :)
thanks
Steve
On 26 Mar 2016, at 00:08, Andrew Johnson <[email protected]> wrote:
> 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 Michael Davidsaver
- References:
- Re: error return from ao device support Andrew Johnson
- Navigate by Date:
- Prev:
Re: error return from ao device support Andrew Johnson
- Next:
Re: error return from ao device support Michael Davidsaver
- 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:
Re: error return from ao device support Andrew Johnson
- Next:
Re: error return from ao device support Michael Davidsaver
- 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
|