Experimental Physics and
Industrial Control System

"J. Frederick Bartlett" <[email protected]> · Fri, 12 Dec 2003 11:48:36 -0600

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
> >
> >
> >
>
>
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System