Geoff,
I am unable to reproduce the behavior you describe with
vxWorks 5.4 / pc486 BSP and EPICS R3.13.3 at our site.
Do you see this problem only with ca_test or do other IOC
initiated CA connections from the sequencer or the database
links also fail?
Does ca_test fail to connect to this IOC when it is run from
a workstation?
Does your network have many devices that are configured with
the wrong subnet mask. If so this can cause problems with
CA broadcasting based name resolution. This can be detected
if you run "snoop icmp" on a Solaris machine and you
see many ICMP destination unreachable responses to CA's
broadcasted attempts to find process variables.
I notice that the R3.14 version of ca_test has been upgraded to
call ca_clear_channel() and ca_task_exit() to clean up before it
returns. This might result in improved behavior under vxWorks.
Nevertheless, I was unable to reproduce your problem with the
earlier R3.13 version of ca_test on vxWorks 5.4.
Running a CA program on vxWorks directly from the shell can
be problematic because (on vxWorks 5.4) the shell by default
runs at one notch below the highest possible priority. This might
cause problems because CA spawns off various auxiliary threads
that run at priorities above and below the priority of the
initiating thread. You could avoid these problems
by spawning ca_test to run at a lower priority. Nevertheless, I
was unable to reproduce your problem with the earlier R3.13
version of ca_test initiating at the shells default priority
(on vxWorks 5.4 this is priority level 1). Imp not certain of
this, but I seem to recall that earlier version (possibly
your vxWorks 5.3.1) run the shell at the very highest priority
(priority level 0).
Make certain that the ca_test that you are using was compiled
against the same version of EPICS that you have loaded into your
IOC.
Jeff
> -----Original Message-----
> From: Geoff Savage [mailto:[email protected]]
> Sent: Thursday, March 29, 2001 10:00 AM
> To: [email protected]
> Subject: Re: ca client connection pattern
>
>
> I neglected to include an error message. Here is the same command
> (ca_test) issued three times in a row.
>
> -> ld < ca_test.o
>
> value = 67088952 = 0x3ffb238
> -> ca_test "CTL_PROC_00/MEM"
>
> Not Found CTL_PROC_00/MEM
> value = -1 = 0xffffffff = dataMutex + 0xfc22c4f7
> ->
> ->
> ->
> ->
> -> ca_test "CTL_PROC_00/MEM"
>
> name: CTL_PROC_00/MEM
> native type: -1
> native count: 0
> CA.Client.Diagnostic..............................................
> Message: "The request was ignored because the specified channel is
> disconnec
> ted"
> Severity: Error
> Source File: ../ca_test.c Line Number: 193
>
> < I hit ^C here >
>
> 178934 vxTaskEntry +60 : shell ()
> 155cbc shell +18c: 155ce8 ()
> 155ef0 shell +3c0: execute ()
> 156070 execute +d8 : yyparse ()
> 18ef78 yyparse +7a8: 18cedc ()
> 18d054 yystart +8f8: ca_test ()
> 3b790a0 ca_test +18 : 3b79120 ()
> 3b79348 ca_test +2c0: ca_signal_with_file_and_lineno ()
> 3c97eac ca_signal_with_file_and_lineno+12c: taskSuspend ()
> tShell restarted.
>
> -> ca_test "CTL_PROC_00/MEM"
>
> name: CTL_PROC_00/MEM
> native type: 6
> native count: 1
> DBR_STRING 57.60
> DBR_SHORT 57
> DBR_FLOAT 57.6009
> DBR_ENUM 57
> DBR_CHAR 57
> DBR_LONG
> 57
> DBR_DOUBLE 57.6009
> DBR_STS_STRING 0 0 Value: 57.60
> DBR_STS_SHORT 0 0 Value: 57
> DBR_STS_FLOAT 0 0 Value: 57.6009
> DBR_STS_ENUM 0 0 Value: 57
> DBR_STS_CHAR 0 0 Value: 57
> DBR_STS_LONG 0 0 Value: 57
> DBR_STS_DOUBLE 0 0 Value: 57.6009
> DBR_TIME_STRING 0 0 TimeStamp: 03/29/01 10:52:12.908292763 Value:
> 57.60
> DBR_TIME_SHORT 0 0 TimeStamp: 03/29/01 10:52:12.908292763 Value:
> 57
> DBR_TIME_FLOAT 0 0 TimeStamp: 03/29/01 10:52:12.908292763 Value:
> 57.6009
> DBR_TIME_ENUM 0 0 TimeStamp: 03/29/01 10:52:12.908292763 Value:
> 57
> DBR_TIME_CHAR 0 0 TimeStamp: 03/29/01 10:52:12.908292763 Value:
> 57
> DBR_TIME_LONG 0 0 TimeStamp: 03/29/01 10:52:12.908292763 Value:
> 57
> DBR_TIME_DOUBLE 0 0 TimeStamp: 03/29/01 10:52:12.908292763 Value:
> 57.6009
> DBR_GR_STRING 0 0 Value: 57.60
> DBR_GR_SHORT 0 0
> 100 0 90 60 0 0 Value:
> 57
> DBR_GR_FLOAT 0 0 2
> 100.000 0.000 90.000 60.000 0.000 0.000 Value:
> 57.6009
> DBR_GR_ENUM 0 0 Value: 57
> DBR_GR_CHAR 0 0
> 100 0 90 60 0 0 Value:
> 57
> DBR_GR_LONG 0 0
> 100 0 90 60 0 0 Value:
> 57
> DBR_GR_DOUBLE 0 0 2
> 100.000 0.000 90.000 60.000 0.000 0.000 Value:
> 57.6009
> DBR_CTRL_STRING 0 0 Value: 57.60
> DBR_CTRL_SHORT 0 0
> 100 0 90 60 0 0
> 100 0
> Value: 57
> DBR_CTRL_FLOAT 0 0 2
> 100.000 0.000 90.000 60.000 0.000 0.000
> 100.000 0.000
> Value: 57.6009
> DBR_CTRL_ENUM 0 0 Value: 57
> DBR_CTRL_CHAR 0 0
> 100 0 90 60 0 0
> 100 0
> Value: 57
> DBR_CTRL_LONG 0 0
> 100 0 90 60 0 0
> 100 0
> Value: 57
> DBR_CTRL_DOUBLE 0 0 2
> 100.000 0.000 90.000 60.000 0.000 0.000
> 100.000 0.000
> Value: 57.600948
>
>
> value = 0 = 0x0
> ->
>
> Geoff Savage wrote:
> >
> > Hi,
> >
> > I'm running a ca client on an ioc and connecting to pv on a different
> > ioc. On one boot of the processor the connection happens with no
> > problems. On the next boot of the processor the connection attempt
> > fails. This pattern has continued for the last two days. The ca client
> > processor is an mv2304 and pv processor has been an mv162 and mv2301.
> >
> > I have tested the connections between the processors with ping.
> >
> > Any ideas?
> >
> > Thanks
> >
> > Geoff
- Replies:
- Re: ca client connection pattern Geoff Savage
- References:
- Re: ca client connection pattern Geoff Savage
- Navigate by Date:
- Prev:
medm window resizing Paul Sichta
- Next:
Re: ca client connection pattern Geoff Savage
- 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: ca client connection pattern Geoff Savage
- Next:
Re: ca client connection pattern Geoff Savage
- 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
·