Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: RE: Problems with Channel Access calls on an IOC moving from R3.13.7 -> 3.14.8
From: "Jeff Hill" <johill@lanl.gov>
To: "'Hammonds, John P.'" <jphammonds@anl.gov>, <tech-talk@aps.anl.gov>
Date: Wed, 6 Dec 2006 14:08:03 -0700

John,

 

The ETIMEDOUT indicates that there are problems building a TCP/IP circuit to 192.168.6.101:5064. To get that far the UDP services on 192.168.6.101:5064 must have been responding ok so presumably the local host has a route to 192.168.6.101. Nevertheless you might try pinging 192.168.6.101 from this host. Modern versions of vxWorks include the ping command, or not, depending on build options. Depending on the options you supply to the ping command you can get some coarse information about network responsiveness. You might also look at ifShow to see if there are any link errors on either host. You might also test to see if the IP kernel is working before and after this code runs. A change might indicate corruption of the IP kernel’s data structures.

 

I can’t speculate about the exception with instruction address 0x4 other than to guess that the code was clobbered or a nill function pointer was used. I might be able to make further guesses if you sent the output from “tt <task id>” in this case “tt 0x275bfd8”.  This will provide a stack trace. There are also ways to request a stack trace from the debugging facilities supplied with Tornado.

 

Note also that “preemptive callback mode” was the default for vxWorks prior to R3.14, but in R3.14 non-preemptive mode is the default and you must specifically request “preemptive callback mode” invariant of the OS you are running on. This maybe wouldn’t be a significant issue with the pseudo code that you sent.

 

Jeff

 

 


From: Hammonds, John P. [mailto:jphammonds@anl.gov]
Sent: Wednesday, December 06, 2006 12:37 PM
To: tech-talk@aps.anl.gov
Subject: Problems with Channel Access calls on an IOC moving from R3.13.7 -> 3.14.8

 

I am working on moving our detector data acquisition code from R3.13.7 to R3.14.8 and am having trouble with a piece of the code that makes channel access calls from C code.  I have 2 crates both running as VxWorks IOC.  One of these is a master crate that reads setup data from a file and loads this into the iocs.  The slave crate basically handles Sample environment and beamline control stuff.  The master crate does ca_put C library call to write data to the slave crate.  On moving this to R3.14.8 I am having trouble getting connection between the crates.  The basic code does

      ca_create_channel()  ( Under 3.13 I was using ca_search())

      ca_pend_io()  I now added code to check for ECA_NORMAL

      ca_put()

      ca_pend_io()

ca_clear_channel()

 

I get the following messages coming out of the IOC.  This code has worked well under 3.13.  Anyone have ideas for what could be going on here?

 

     

 

 

iocsand1> CAC: Unable to connect because "S_errno_ETIMEDOUT"

CA.Client.Exception...............................................

    Warning: "Virtual circuit disconnect"

    Context: "192.168.6.101:5064"

    Source File: ../cac.cpp line 1142

    Current Time: WED DEC 06 2006 11:41:56.170496250 ..................................................................

CAC: Unable to connect because "S_errno_ETIMEDOUT"

CA.Client.Exception...............................................

    Warning: "Virtual circuit disconnect"

    Context: "192.168.6.101:5064"

    Source File: ../cac.cpp line 1142

    Current Time: WED DEC 06 2006 11:43:16.170493050 ..................................................................

CAC: Unable to connect because "S_errno_ETIMEDOUT"

CA.Client.Exception...............................................

    Warning: "Virtual circuit disconnect"

    Context: "192.168.6.101:5064"

    Source File: ../cac.cpp line 1142

    Current Time: WED DEC 06 2006 11:44:36.170489850 ..................................................................

Setting sand0A:chngr_0:veto.DESC to SAND Sample Chan

 

program

Exception current instruction address: 0x00000004 Machine Status Register: 0x0008b030 Condition Register: 0x44000049

Task: 0x275bfd8 "ipns_daq"

filename="../../../src/libCom/taskwd/taskwd.c" line number=174 task 0x275bfd8 suspended

           

 

John Hammonds

Data Acquisition Systems Manager

Intense Pulsed Neutron Source

JPHammonds@anl.gov

(630)252-5317

 


Replies:
RE: Problems with Channel Access calls on an IOC moving from R3.13.7 -> 3.14.8 Hammonds, John P.

Navigate by Date:
Prev: Re: wxPython timer and KEK CaPython314 cause core dump Zhong Ren
Next: SLAC Controls Department Position for LCLS Shoaee, Hamid
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: RE: JCA, Gateways and EPICS_CA_ADDR_LIST Rees, NP (Nick)
Next: RE: Problems with Channel Access calls on an IOC moving from R3.13.7 -> 3.14.8 Hammonds, John P.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·