Re: How to deal with LINK_ALARM

[Ralph Lange <ralph.lange@gmx.de>]

Starting from 3.15, you can set the UDFS (UDF Severity) field to the severity that you want an undefined record to be in.

Cheers,
~Ralph

On Tue, Jun 6, 2017 at 11:14 AM, Mark Rivers <rivers@cars.uchicago.edu> wrote:

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