Experimental Physics and
Industrial Control System
| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 <2006> 2007 2008 2009 2010 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 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | RE: Problems with Channel Access calls on an IOC moving from R3.13.7 -> 3.14.8 |
| From: | "Jeff Hill" <[email protected]> |
| To: | "'Hammonds, John P.'" <[email protected]>, <[email protected]> |
| 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:[email protected]]
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 (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 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
- 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 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·