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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: How to deal with LINK_ALARM |
From: | Ralph Lange <[email protected]> |
To: | EPICS Tech Talk <[email protected]> |
Date: | Tue, 6 Jun 2017 11:47:25 -0400 |
Hi Pilar,
First, it is not necessarily a problem that the record has UDF_ALARM after iocInit. This just means that the hardware value may not be initialized because the record has not yet communicated with the hardware.
There are 2 ways to eliminate the UDF_ALARM at iocInit with asyn device support.
1) For all output records asyn device support attempts to do an initial read of the value from your driver in init_record. If that read returns ASYN_SUCCESS (0) then the output record VAL field will be initialized based on the value read, and prec->udf will be 0, and there will not be a UDF_ALARM. This is because the value in your output record is now known to agree with the hardware. Since your record is in UDF_ALARM I think your driver must be returning an error on that initial read operation.
2) You can set PINI=YES, but that will actually write to the hardware which you may or may not want to do when the IOC boots.
Mark
-----Original Message-----
From: Pilar [mailto:pilar.gil@sevensols.com ]
Sent: Tuesday, June 06, 2017 7:05 AM
To: Mark Rivers; [email protected]
Subject: Re: How to deal with LINK_ALARM
Sorry, I have checked it and you are right the alarm is UDF_ALARM.
And in this case ...how is the right way to solve this problem? Setting
field(PINI, "YES") ? Or do I need to check something else?
Sorry I am really new in this field.
Pilar
On 06/06/17 14:00, Mark Rivers wrote:
> Please verify the alarm status using "cainfo" from the shell and "dbpr" from the IOC shell