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: RE: CA problem w EPICS 3.14.11 & VxWorks 6.7
From: "Jeff Hill" <johill@lanl.gov>
To: "'GOURNAY Jean-Francois'" <jean-francois.gournay@cea.fr>, <tech-talk@aps.anl.gov>, "'Kazuro FURUKAWA'" <kazuro.furukawa@kek.jp>
Date: Wed, 25 Nov 2009 09:55:42 -0700

Jean Francois,

 

The “Channel Access Address List” printout from the ‘casr “1”’ ( ‘casr 3’ and ‘dbcar “VME-TST-CA-O”, 3’ are preferable) diagnostic indicates that the auto-configured address list is empty. That certainly is very consistent with what Kazuro-san is reporting. I cc’d to Janet, and perhaps she can update the next release of the build files.

 

If Okazaki-san’s fix isn’t sufficient let me know, and I will take another look.

 

Cheers,

 

Jeff


______________________________________________________
Jeffrey O. Hill           Email       
johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

 

Message content: TSPA

 

From: GOURNAY Jean-Francois [mailto:jean-francois.gournay@cea.fr]
Sent: Wednesday, November 25, 2009 3:28 AM
To: Jeff Hill; tech-talk@aps.anl.gov; Kazuro FURUKAWA
Subject: RE: CA problem w EPICS 3.14.11 & VxWorks 6.7

 

Hello Jeff, hello Kazuro

 

Thanks for your replies.

 

Jeff,

I have included the trace of the 2 following commands  :

 

Dbcar “VMETST-CA-O”, “2”

Casr “1”

 

Before these commands, I did a dbtr “VMETST-CA-O”, surprisingly UDF becomes 0 but the value (supposed to be retrieved through a CA link to VMETST) is 0 (it should be “223”).

Both VxWorks IOCs are on the same network (132.166.33.10 and 132.166.33.11)

 

Kazuro,

I will pass the information to my colleague in charge of the VxWorks support. He had already a lot of trouble with the IP stack of the new release of VxWorks (2nd Ethernet port of our MVME5500 not working, problem of connection with rlogin, problem with connect function of socket.h). Recompiling with gnu instead of diab helps for some point (wancomEnd.c) but there are still pending problems.

 

J.F. Gournay

CEA Saclay

IRFU/SIS


De : Jeff Hill [mailto:johill@lanl.gov]
Envoyé : mardi 24 novembre 2009 18:15
À : GOURNAY Jean-Francois; tech-talk@aps.anl.gov
Objet : RE: CA problem w EPICS 3.14.11 & VxWorks 6.7

 

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       
johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

 

Message content: TSPA

 

From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of GOURNAY Jean-Francois
Sent: Tuesday, November 24, 2009 7:38 AM
To: tech-talk@aps.anl.gov
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

 


References:
CA problem w EPICS 3.14.11 & VxWorks 6.7 GOURNAY Jean-Francois
RE: CA problem w EPICS 3.14.11 & VxWorks 6.7 Jeff Hill
RE: CA problem w EPICS 3.14.11 & VxWorks 6.7 GOURNAY Jean-Francois

Navigate by Date:
Prev: RE: (Another) Modbus problem Mark Rivers
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 
Navigate by Thread:
Prev: Re: CA problem w EPICS 3.14.11 & VxWorks 6.7 Kazuro FURUKAWA
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 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·