Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Fwd: CA link behavior
From: Geoff Savage <savage@fnal.gov>
To: Tech-talk Talk <tech-talk@aps.anl.gov>
Date: Mon, 23 Nov 2009 16:52:43 -0600
Here are the details of my testing with a summary preceding.

Thanks for taking a look,  Geoff

Summary:
EPICS R3.14.8.2 on VxWorks 5.5 - no significant patches.

IOC A      IOC B
so ------> mbbo

Action: Boot both IOCs at the same time.

Action: Reboot IOC B.
IOC A - CA disconnect message
camonitor - CA disconnect message
mbbo 2009-11-23 14:31:01.368860 *** disconnected
mbbo                           <undefined> DEFAULT UDF INVALID

Action: Reboot IOC A - no change.

Action: Process "so" record by writing to "so.PROC" from CA client on host.
IOC B - CAS-client: Process so
IOC A - CAS-client: Process mbbo
camonitor -
mbbo                           2009-11-23 14:34:19.586319 OFF

Action: Reboot IOC B.
IOC B - CAS-client: Process mbbo
camonitor -
mbbo                           <undefined> DEFAULT UDF INVALID
mbbo                           2009-11-23 14:38:58.308664 OFF


Details:
IOC A      IOC B
so ------> mbbo

IOC A (mv2304, d0olctl145)
record(stringout, "so")
{
  field(DTYP, "Soft Channel")
  field(OUT,  "mbbo")
  field(VAL,  "OFF")
  field(SCAN, "Passive")
  field(OMSL, "supervisory")
  field(TPRO, "1")
}
-> dblsr "so", 2
globalLock 0x2e55590
lockSetModifyLock 0x2e55520
Lock Set 1 1 members epicsMutexId 0x2e729c0 Not Locked
so
value = 0 = 0x0

IOC B (mv2300, d0olctl34)
record(mbbo, "mbbo")
{
  field(DTYP, "Soft Channel")
  field(OUT,  "0")
  field(SHFT, "0")
  field(NOBT, "8")
  field(OMSL, "supervisory")
  field(ZRST, "DEFAULT")
  field(ZRVL, "0")
  field(ONST, "ON")
  field(ONVL, "1")
  field(TWST, "OFF")
  field(TWVL, "2")
  field(TPRO, "1")
}
-> dblsr "mbbo", 2
globalLock 0xc32d78
lockSetModifyLock 0xc32d28
Lock Set 1 1 members epicsMutexId 0xc32c80 Not Locked
mbbo
value = 0 = 0x0

Boot both IOCs.

Start camonitor on a Linux host -
> camonitor mbbo
mbbo                           <undefined> DEFAULT UDF INVALID

Reboot IOC B

camonitor output -
Unexpected problem with CA circuit to server "d0olctl34.fnal.gov:5064" was "Connection reset by peer" - disconnecting
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "d0olctl34.fnal.gov:5064"
    Source File: ../cac.cpp line 1142
    Current Time: Mon Nov 23 2009 14:31:01.368765000
..................................................................

Printed on IOC A -
Unexpected problem with CA circuit to server "d0olctl34.fnal.gov:5064" was "S_errno_ECONNRESET" - disconnecting DB CA Link Exception: "Virtual circuit disconnect", context "d0olctl34.fnal.gov:5064"

camonitor output when IOC B finishes reboot -
mbbo 2009-11-23 14:31:01.368860 *** disconnected
mbbo                           <undefined> DEFAULT UDF INVALID

Reboot IOC A
nothing changes

Write to so.PROC. (so sends "OFF" to mbbo)
IOC B - CAS-client: Process so
IOC A - CAS-client: Process mbbo
camonitor -
mbbo                           2009-11-23 14:34:19.586319 OFF

Reboot IOC B
camonitor output -
Unexpected problem with CA circuit to server "d0olctl34.fnal.gov:5064" was "Connection reset by peer" - disconnecting
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "d0olctl34.fnal.gov:5064"
    Source File: ../cac.cpp line 1142
    Current Time: Mon Nov 23 2009 14:38:33.260917000
..................................................................
mbbo 2009-11-23 14:38:33.261021 *** disconnected

Printed on IOC A -
Unexpected problem with CA circuit to server "d0olctl34.fnal.gov:5064" was "S_errno_ECONNRESET" - disconnecting DB CA Link Exception: "Virtual circuit disconnect", context "d0olctl34.fnal.gov:5064"

camonitor output when IOC B finishes reboot -
mbbo                           <undefined> DEFAULT UDF INVALID
mbbo                           2009-11-23 14:38:58.308664 OFF
IOC B - CAS-client: Process mbbo



Summary:
EPICS R3.14.8.2 - no significant patches.

IOC A      IOC B
so ------> mbbo

Boot both IOCs.

Action: Reboot IOC B - no change.
IOC A - CA disconnect message
camonitor - CA disconnect message
mbbo 2009-11-23 14:31:01.368860 *** disconnected
mbbo                           <undefined> DEFAULT UDF INVALID

Action: Reboot IOC A - no change.

Action: Process "so" record by writing to "so.PROC" from CA client on host.
IOC B - CAS-client: Process so
IOC A - CAS-client: Process mbbo
camonitor -
mbbo                           2009-11-23 14:34:19.586319 OFF

Action: Reboot IOC B
IOC B - CAS-client: Process mbbo
camonitor -
mbbo                           <undefined> DEFAULT UDF INVALID
mbbo                           2009-11-23 14:38:58.308664 OFF



Begin forwarded message:

From: Andrew Johnson <anj@aps.anl.gov>
Date: November 13, 2009 2:24:28 PM CST
To: tech-talk@aps.anl.gov
Cc: Geoff Savage <savage@fnal.gov>
Subject: Re: CA link behavior

Hi Geoff,

On Friday 13 November 2009 13:38:36 Geoff Savage wrote:

I have a passive stringout record in IOC A whose OUTLINK references an
mbbo record in IOC B.  When I reboot IOC B the value in the stringout
record is written to the mbbo record even though the stringout record
has not been processed.

A bit more background.  The stringout record will be processed by a
calc record when a temperature becomes too high.  The mbbo record
controls the power to a front end board.  So the value being written
is to power off the front end board whenever the IOC B is rebooted.

This doesn't sound like it should be happening, unless there's something else going on. Have you tried setting TPRO on the mbbo record? The output from
   dblsr "<mbboRecordName>", 2
might provide some more clues as well.

Can you post the two complete record definitions extracted from their .db files, and the output from dbpr on both records with an interest level 3 or higher. Also the Base version number that you're running (and whether it contains any significant modifications to the official release), and the
target architectures of the two IOCs for completeness sake.

- Andrew
--
The best FOSS code is written to be read by other humans -- Harald Welte



Replies:
Re: Fwd: CA link behavior Andrew Johnson
References:
Re: CA link behavior Andrew Johnson

Navigate by Date:
Prev: RE: error building mca6-11 Mark Rivers
Next: CA problem w EPICS 3.14.11 & VxWorks 6.7 GOURNAY Jean-Francois
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: CA link behavior Emmanuel Mayssat
Next: Re: Fwd: CA link behavior Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·