Experimental Physics and
Industrial Control System

 

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 (2^nd 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.

 

 

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