Experimental Physics and
Industrial Control System

"J. Frederick Bartlett" <[email protected]> · Mon, 15 Dec 2003 15:18:12 -0600

Marty,

  I believe that I have now reduced the problem example to its bare
essentials. The .db file that is attached to this note is a abstraction of
the records that I use to manage power control to a set of detector
electronic crates. The actual details are not relevant to the problem;
however, you might be interested in the environment in which the original
problem appeared.

  The experiment uses a 16-bit register on an external field bus
(MIL/STD1553B, asynchronous device support) to control the AC power to a set
of electronic crates. Each bit in the 16-bit word controls the power to a
separate crate. These bits must function independently, i.e. changing one of
them must not affect any of the others. Each bit is represented by (1) an
mbbi record, with appropriate alarms, that follows the state of the bit, (2)
an mbbo record that provides a means of changing the state of the bit, and
(3) a calcout record that performs the mask-and-merge operations required to
achieve the bit-level read-modify-write action.

  The mbbi records get their data input from a longin record that
periodically reads the external control register. That same longin record is
the start of a forward-link chain that visits all 16 of the mbbi records,
updating them each time the longin record processes.

  The 16 mbbo records trigger and provide inputs (a data value and a mask)
to the 16 calc records; and the calcout records output to a longout record
that writes to the external control register. The longout record is also
forward-linked to the longin record to assure that it (the longin record)
and the mbbi records are quickly updated each time that the external control
register is modified.

  The problem is that the first time an mbbo record is modified, its
corresponding calcout record declares an INVALID severity and LINK
(INVALID/LINK) status error. Further, the source of the LINK error is the
input link back to the mbbo record to pick up its MASK field.

  The attached .db file, which is an abstracted version of the power control
problem without the readback chain, has three records: a longin record to
represent the current value of the external register, an mbbo record to
control one of the bits, and a calcout record to perform the
read-modify-write action for that bit. The attached PowerPoint file shows
the state of the three records: (A) The initial state after writing to the
PROC field of devRegister to clear the INVALID/UDF alarm state, (B) the
state after writing an "ON" string to the mbbo record, and (C) the final
state after writing an "OFF" string to the mbbo record.

  Note that in state B the calcout record has an INVALID/LINK alarm which is
caused by the input link to the MASK field of the mbbo record. I have
confirmed this by changing the maximize severity attribute of the link from
"MS" to "NMS".

											Fritz

> -----Original Message-----
> From: Marty Kraimer [mailto:[email protected]]
> Sent: Monday, December 15, 2003 8:58 AM
> To: J. Frederick Bartlett
> Subject: Re: Spurious link alarms generated?
>
>
> Can you create a simple example with just two records and no
> macros that shows
> the problem?
>
> I tried the example you sent and can't see how to run it.
>
> What does $(ilnk) reference? Note that you gave
>
> record(calcout, "$(det)_PWR_$(loc)/CALC")
>    {
>    field(DESC, "PDT-$(loc) power control")
>    field(CALC, "(A&~B)|C")
>    field(INPA, "$(ilnk) NPP MS")
>
> What is the status of $(ilnk) the first time the calcout record
> is processed?
>
> What are the fields ASND, EXPT in the mbbi record? They are not
> in the mbbi
> record in base.
>
> Marty
>
> J. Frederick Bartlett wrote:
> > Marty,
> >
> >   Record A (CTL_RM_07P/BIN00:R) is longin and record B
> (CTL_PWR_P0/STATE) is
> > mbbi.
> >
> > Here is the result from camonitor:
> >
> > 	<d0olb> camonitor CTL_RM_07P/BIN00:R CTL_PWR_P0/STATE
> >  	CTL_RM_07P/BIN00:R             12/12/03 17:24:01.276913320 0
> >  	CTL_PWR_P0/STATE               12/12/03 17:24:01.276913320 ON
> >
> >   I have another example that behaves the same way, where
> record A is a mbbo
> > and record B is a calc. Record A writes to one of the input
> value fields of
> > the calc record, which is "Passive", with the "process-passive" (PP)
> > attribute set. The calc record, when it processes, retrieves a mask (the
> > MASK field) from record A with the "maximize-severity"
> attribute set. The
> > first execution of the calc record results in an INVALID
> severity and LINK
> > status because of the link back to record A. I have attached
> the template
> > file that defines these records.
> >
> >
> 	Fritz
> >
> >
> >>-----Original Message-----
> >>From: Marty Kraimer [mailto:[email protected]]
> >>Sent: Friday, December 12, 2003 1:19 PM
> >>To: J. Frederick Bartlett
> >>Subject: Re: Spurious link alarms generated?
> >>
> >>
> >>What are the record types?
> >>
> >>This is really strange.
> >>
> >>Also run
> >>
> >>camonitor CTL_RM_07P/BIN00:R CTL_PWR_P0/STATE
> >>
> >>before booting the ioc.
> >>
> >>Marty
> >>
> >>J. Frederick Bartlett wrote:
> >>
> >>>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
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System