invalid link status with CALC record

[Jeff Hill]

From Pam Gurd:

Here is the situation, right after my IOC reboots:

This record is a CALC record with 2 links, one to itself and one to a record in another IOC.

The record in the other IOC does not change right now (it’s pegged at its maximum). But it is certainly valid.

It seems like the “MS” in the CA link causes the record never to clear the LINK status – maybe it thinks, because one of the records it is linked to (itself) is invalid, it shouldn’t clear the invalid status.

I can clear this status by setting INPA to the same value without MS and back again.

I am not sure who I should write to with this (maybe it’s in the CALC record, who is supporting the CALC record?)

dbpr "CCL_HPRF:RFWin302:Flow",4

A: 2.59098887443542 ACKS: INVALID ACKT: YES ADEL: 0

ALST: 2.5909888744354 ASG: ASP: 0x01515290

B: 2.5909888744354 BKPT: 0x00 C: 60

CALC: C?((B*(C-1)+A)/C):A D: 0 DESC:

DISA: 0 DISP: 0 DISS: NO_ALARM DISV: 1

DPVT: 0x00000000 DSET: 0x00000000 DTYP: <nil> E: 0

EGU: gpm EVNT: 0 F: 0 FLNK:CONSTANT 0

G: 0 H: 0 HHSV: NO_ALARM HIGH: 0

HIHI: 0 HOPR: 0 HSV: NO_ALARM HYST: 0

I: 0 INPA:CA_LINK SCL_Cool:FT507:RFW6_Rtn NPP MS

INPB:DB_LINK CCL_HPRF:RFWin302:Flow.VAL NPP NMS INPC:CONSTANT 60

INPD:CONSTANT INPE:CONSTANT INPF:CONSTANT INPG:CONSTANT

INPH:CONSTANT INPI:CONSTANT INPJ:CONSTANT INPK:CONSTANT

INPL:CONSTANT J: 0 K: 0 L: 0

LA: 2.59098887443542 LALM: 2.5909888744354

LB: 2.5909888744354 LC: 60 LCNT: 0 LD: 0

LE: 0 LF: 0 LG: 0 LH: 0

LI: 0 LJ: 0 LK: 0 LL: 0

LLSV: NO_ALARM LOLO: 0 LOPR: 0 LOW: 0

LSET: 0x015c01b8 LSV: NO_ALARM MDEL: 0

MLIS: 0x008c4570008c457000000001 MLOK: 0x0169ead8

MLST: 2.5909888744354 NAME: CCL_HPRF:RFWin302:Flow

NSEV: NO_ALARM NSTA: NO_ALARM PACT: 0 PHAS: 0

PINI: NO PPN: 0x00000000 PPNR: 0x00000000 PREC: 3

PRIO: LOW PROC: 0 PUTF: 0 RDES: 0x01b1a488

RPCL: 0x03460203483ff00000000000003031012f033225 RPRO: 0

RSET: 0x01aba610 SCAN: 1 second SDIS:CONSTANT SEVR: INVALID

SPVT: 0x01555020 STAT: LINK TIME: 0x1b864e611fa02bca

TPRO: 0 TSE: 0 TSEL:CONSTANT UDF: 0

VAL: 2.5909888744354

value = 0 = 0x0

Original Mantis Bug: mantis-118
    http://www.aps.anl.gov/epics/mantis/view_bug_page.php?f_id=118

[Jeff Hill (johill-lanl)]

From Andrew Johnson:

The evidence from Pam in your message is insufficient to be sure whether
there is any kind of bug in Base or not - we also need a dbpr from the
other record to know if it's in INVALID_ALARM severity or not, since the
LINK_ALARM status could very easily be caused by the MS flag on the CA
link. It is unfortunate that we use the same alarm status value to mean
two different things, but that's the current situation so we can't
presently distinuish between them.

To clarify those two cases, a record with STAT=LINK could be signalling
either of these:
1. One of its input or output links is pointing to a non-existant PV
2. One of its input links with the MS flag set received a value with an
alarm severity, in Pam's case INVALID_ALARM.

[Jeff Hill (johill-lanl)]

From Andrew Johnson:

Gurd, Pamela A. wrote:
> I wouldn't be asking about it if there was an alarm set on the other
> record.

I wasn't sure of that from Jeff's email, and I can't currently offer any
other explanation as I'm unable to replicate the behaviour you reported
any other way, using a CALC record which apart from the record names is
identical to yours. I've been trying independent of Marty's efforts last
week.

I would recommend that you do a 'casr 1' on the remote IOC and make sure
that the TCP circuit between the two IOCs is still active, meaning that
the "Secs since last send" field is a reasonable value given the expected
monitor frequencies down that TCP channel. I don't have anything else to
suggest.

[Jeff Hill (johill-lanl)]

From Pam Gurd:

Unfortunately, or possibly fortunately, the problem has gone away for
the moment. (Until 2 am some time...)

[Jeff Hill (johill-lanl)]

From Marty Kraimer:

Last week Pam and I had several Email messages about this problem.
The following describes my attempt to reproduce the problem Pam has.
I could NOT reproduce it.

Unless we can have an example we can reproduce at APS, it is hard for
use at APS to provide help.

Can someone at SNS help Pam create a small example that demonstrates the
problem?

I tried to reproduce the problem with two vxWorks IOCs I have.

The ioc that has a link to another ioc, which I will call iocRemote, has
the record

record(calc, "calcExample")
{
        field(DESC, "Counter")
        field(SCAN,"1 second")
        field(CALC, "(A<10)?A:10")
        field(INPA, "exampleSource MS")
        field(INPB, "calcExample NPP NMS")
}

The remote IOC has the record

record(calc, "exampleSource")
{
        field(DESC, "Counter")
        field(SCAN,"1 second")
        field(CALC, "(A<B)?(A+C):D")
        field(INPA, "exampleSource NPP NMS")
        field(INPB, "9")
        field(INPC, "1")
        field(INPD, "0")
        field(EGU, "Counts")
        field(HOPR, "10")
        field(HIHI, "8")
        field(HIGH, "6")
        field(LOW, "4")
        field(LOLO, "2")
        field(HHSV, "MAJOR")
        field(HSV, "MINOR")
        field(LSV, "MINOR")
        field(LLSV, "MAJOR")
}

When I run the test the SEVR for record calcExample just reflects the
SEVR of record exampleSource. The STAT for calcExample is LINK_ALARM if
exampleSource is in alarm and NO_ALARM otherwise.
For example:

iocdemo> dbpr "calcExample"
A: 3 ASG: B: 2 C:
0
CALC: (A<10)?A:10 D: 0 DESC: Counter DISA:
0
DISP: 0 DISV: 1 E: 0 F:
0
G: 0 H: 0 I: 0 J:
0
K: 0 L: 0 NAME: calcExample SEVR:
MINOR
STAT: LINK TPRO: 0 VAL: 3
value = 0 = 0x0
iocdemo> dbpr "calcExample"
A: 5 ASG: B: 4 C:
0
CALC: (A<10)?A:10 D: 0 DESC: Counter DISA:
0
DISP: 0 DISV: 1 E: 0 F:
0
G: 0 H: 0 I: 0 J:
0
K: 0 L: 0 NAME: calcExample SEVR:
NO_ALARM
STAT: NO_ALARM TPRO: 0 VAL: 5

It did not matter which ioc I started first. I got the same results.

[Jeff Hill (johill-lanl)]

From Pam Gurd:

My problem is back again. Here’s what casr 2 says about the channels in question:

TCP 172.31.74.146:1029(ccl-hprf-ioc3): User="vxuser", V4.11, 4 Channels, Priority=80

            Task Id=0x1349018, Socket FD=43
            Secs since last send 2.65, Secs since last receive 2.65
            Unprocessed request bytes=0, Undelivered response bytes=0
            State=up
            1272 bytes allocated
            SCL_Cool:FT509:RFW8_Rtn(1rw) SCL_Cool:FT508:RFW7_Rtn(1rw) SCL_Cool:FT507:RFW6_Rtn(1rw)
            SCL_Cool:FT506:RFW5_Rtn(1rw)

All 4 of the records that link to these PVs are in LINK alarm. The remote IOC was booted on Aug. 26, the local one on Aug. 27. These things were okay after the Aug. 27 reboot.

All 4 of these values are pegged at their maximum: ie, the values are not changing.

[Jeff Hill (johill-lanl)]

We have determined that this is caused by mantis-91 which is already resolved

[Andrew Johnson (anj)]

R3.14.7 Released