EPICS Controls 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  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: CA problem w EPICS 3.14.11 & VxWorks 6.7
From: "Jeff Hill" <[email protected]>
To: "'GOURNAY Jean-Francois'" <[email protected]>, <[email protected]>
Date: Tue, 24 Nov 2009 10:14:56 -0700

Hello Jean-Francois,

 

I had a quick look at what has changed between R3.14.10 and R3.14.11 WRT EPICS_CA_AUTO_ADDR_LIST and EPICS_CA_ADDR_LIST. I do see that in R3.14.11 Mantis 331 was fixed. This is certainly a relevant change, but I don’t at this time expect the side effect that you are observing.

 

Ø  This problem arises also with CA links between VxWorks an Linux.

Ø  On the other hand, no problem with CA links between 2 Linux IOCs

 

The above might be a very useful bit of information. Presumably the same vxWorks version, vxWorks 6.7, was also used with R3.14.10? Frequently vxWorks systems boot by default with routes limiting access only to the local subnet. If a EPICS system is operating in a WAN environment it may be necessary to configure routes into the vxWorks system which enable a vxWorks based CA server to respond to requests originating outside it's subnet. These routing restrictions might also apply to vxWorks based CA clients communicating with off subnet servers. See "routeLib" in the vxWorks reference manual.

 

Of course, the other difference between vxWorks and Linux in your situation might be PPC (big-endian) versus Intel (little-endian), and that might imply a missing byte swap in the CA code, but I haven’t identified one at this time based on the source code differences.

 

Ø  We have “CA beacon routing … ECONNREFUSED” on the 1st booted IOC.

 

This indicates that the IOC is unable to identify a route for a beacon message. A list of addresses is also configured for the beacons. When EPICS_CA_AUTO_ADDR_LIST is YES, please type ‘casr <integer interest level>’ and send the result. This will reveal what the address list is being set to at higher interest levels. One can also receive an overwhelming amount of information by typing ‘dbcar “record name”, <integer interest level>’. At some higher interest level you should see also the CA address list for the db ca client. You might also try “routeShow” on this vxWorks system. If there is a problem with auto configuring the client’s address list we should see clear evidence in this diagnostic.

 

With the above information, fault isolation should proceed quickly, and maybe I won’t need to spend as much time staring at the source code.

 

Thanks for your help,

 

Jeff

______________________________________________________
Jeffrey O. Hill           Email       
[email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

 

Message content: TSPA

 

From: [email protected] [mailto:[email protected]] On Behalf Of GOURNAY Jean-Francois
Sent: Tuesday, November 24, 2009 7:38 AM
To: [email protected]
Subject: CA problem w EPICS 3.14.11 & VxWorks 6.7

 

Hello,

 

We have 2 IOCs running EPICS 3.14.11 with VxWorks 6.7.

Any record on an IOC with a CA link on a record located in the other IOC stays UDF=1 forever. This problem arises with EPICS_CA_AUTO_ADDR_LIST= YES.

 

With EPICS_CA_AUTO_ADDR_LIST=NO and EPICS-CA-ADDR-LIST= … it works. But we would like to avoid to have this parameter to “NO” and having to maintain the host list in ADDR-LIST.

 

Especially in the case where:

On IOC1 : EPICS-CA-ADDR-LIST=<IP IOC2>

And on IOC2: EPICS-CA-ADDR-LIST=<IP IOC1>

(needed for CA links in both directions)

We have “CA beacon routing … ECONNREFUSED” on the 1rst booted IOC.

 

We did’nt have this problem with the previous release.

This problem arises also with CA links between VxWorks an Linux.

On the other hand, no problem with CA links between 2 Linux IOCs

 

Thanks Jeff (I think it is probably a problem for you . . .)

 

J.F. Gournay

CEA Saclay

IRFU/SIS

 


Replies:
Re: CA problem w EPICS 3.14.11 & VxWorks 6.7 Kazuro FURUKAWA
RE: CA problem w EPICS 3.14.11 & VxWorks 6.7 GOURNAY Jean-Francois
References:
CA problem w EPICS 3.14.11 & VxWorks 6.7 GOURNAY Jean-Francois

Navigate by Date:
Prev: Modbus help emma.shepherd
Next: RE: Modbus help Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: CA problem w EPICS 3.14.11 & VxWorks 6.7 GOURNAY Jean-Francois
Next: Re: CA problem w EPICS 3.14.11 & VxWorks 6.7 Kazuro FURUKAWA
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·