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  2016  <2017 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
<== Date ==> <== Thread ==>

Subject: RE: How to deal with LINK_ALARM
From: Mark Rivers <rivers@cars.uchicago.edu>
To: 'Pilar' <pilar.gil@sevensols.com>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Tue, 6 Jun 2017 15:14:39 +0000
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; tech-talk@aps.anl.gov
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


Replies:
Re: How to deal with LINK_ALARM Ralph Lange
References:
RE: How to deal with LINK_ALARM Mark Rivers
Re: How to deal with LINK_ALARM Pilar
RE: How to deal with LINK_ALARM Mark Rivers
Re: How to deal with LINK_ALARM Pilar

Navigate by Date:
Prev: Re: Force TCP/IP reconnect from Asyn/Streamdevice Christoph Schroeder
Next: RE: Force TCP/IP reconnect from Asyn/Streamdevice Mark Rivers
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
Navigate by Thread:
Prev: Re: How to deal with LINK_ALARM Pilar
Next: Re: How to deal with LINK_ALARM Ralph Lange
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
ANJ, 06 Jun 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·