Marty,
Thanks for the suggestions. I should have mentioned that Record B has a
scan rate of "Passive". Also, PINI is false for both records.
I have followed your diagnostic suggestions. In the following print logs,
Record A is CTL_RM_07P/BIN00:R and Record B is CTL_PWR_P0/STATE. First the
console output after iocInit:
iocInit: All initialization complete
Done executing startup script /online/ioc/ppc/mv2300/d0olctl07/startup
process: CTL_RM_07P/BIN00:R
0xdc18c0 (scan60): dev1553 - read_longin executed
0xe4d258 (Drv1553-00): dev1553 callback - status: 0
0xe60340 (cbMedium): dev1553 - read_longin executed
process: CTL_PWR_P0/STATE
This shows that record A is processed before record B. The additional three
lines are generated by my device support module, which also monitors the
TPRO field. Note that the device support is asynchronous.
Here is the results from the "dblsr" command:
-> dblsr "CTL_PWR_P0/STATE",2
Lock Set 7 2 members Not Locked
CTL_RM_07P/BIN00:R
FLNK FWDLINK NPP NMS CTL_PWR_P0/STATE
CTL_PWR_P0/STATE
INP INLINK NPP MS CTL_RM_07P/BIN00:R
Fritz
> -----Original Message-----
> From: Marty Kraimer [mailto:[email protected]]
> Sent: Friday, December 12, 2003 7:13 AM
> To: J. Frederick Bartlett
> Cc: tech-talk
> Subject: Re: Spurious link alarms generated?
>
>
> This should work as you suggest.
>
> To diagnose:
>
> In the xxx.db file set TPRO true for both A and B.
> At initialization does B get processed before A?
>
> If so then B is processed for some other reason than A linking to it
> a) PINI is TRUE
> b) SCAN is not passive
> c) Another link references B. Issue the command:
> dblsr "<B name>",2
>
> Marty
>
> J. Frederick Bartlett wrote:
> > I have encountered a situation in which spurious (i.e.
> unexpected) link
> > alarms are being generated following the reboot of an IOC. The record
> > connectivity is:
> >
> > Record A has a scan rate of one second
> >
> > Record A has a forward link to record B
> >
> > Record B has an input link in its INP field that references
> record A with
> > "NPP"
> > and "MS" specified.
> >
> > When record A is processed for the first time, record B registers an
> > "INVALID" alarm severity with a "LINK" alarm status. The second
> time that A
> > is processed, the "INVALID" alarm severity is cleared.
> >
> > I believe that, when record B retrieves the value from record
> A during the
> > initial process cycle, the alarm severity that is propagated by the "MS"
> > specification is "INVALID" because record A must, somehow, retain the
> > original "INVALID" severity and the "UDF" status even though it
> has already
> > processed. During subsequent process cycles, record B does not
> generate an
> > "LINK" alarm status because record A no longer has "UDF" alarm status.
> >
> > This behavior is counter-intuitive. The "Application
> Developer's Guide"
> > states that the forward link is not executed until the
> originating record
> > has completed processing. If this is the case, why does an input link to
> > that record transfer the prior (or initial) alarm state?
> >
> > Finally, we are still using release 3.13.4.
> >
> >
> Fritz
> >
> >
> >
>
>
>
- References:
- Re: Spurious link alarms generated? Marty Kraimer
- Navigate by Date:
- Prev:
Re: Insertion Devices Control and EPICS Oleg A. Makarov
- Next:
newport mm4000 motor record hardware(gpib/serial) needs Zhijian Yin
- 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: Spurious link alarms generated? Marty Kraimer
- Next:
RE: Spurious link alarms generated? J. Frederick Bartlett
- 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
|