EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  <20022003  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  <20022003  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: CA client library and Connection handler
From: Adam Jon DeGrush <[email protected]>
To: Brian McAllister <[email protected]>
Cc: <[email protected]>
Date: Thu, 31 Jan 2002 11:19:39 -0500 (EST)
Thanks Brian for the help.

On Thu, 31 Jan 2002, Brian McAllister wrote:

>
> >>> On 1/30/2002 at 19:54:19 EST, Adam Jon DeGrush wrote:
>
>   > I am trying to monitor the connection of channels using
>   > ca_change_connection_event from the client library and am having
>   > difficulty getting it to work. I would like to do a group poll
>   > (synchronous or asynchronously) of my channels at a certain frequency
>   > and would like make sure that my channels are connected before I do
>   > this.

> First, are you "monitoring" your channels (using ca_add_event()) or are you
> using ca_get() in your poll function ?

I was using ca_sg_array_get() for polling in this case. I wasn't doing any
monitoring of channels here but I was planning on installing monitors
using ca_add_event() in the future. Why? Is there problems with this?
 >
> In any case, there is a field in the CHID that holds the status of the
> connection, and a macro defined in cadef.h for accessing it (ca_state()).
> The possible values are cs_never_conn, cs_prev_conn, cs_conn, cs_closed.
>
>   > I though I could just install a connection handler like in the
>   > example:
>   >
>   >   for (pCurrent = pFirst; pCurrent != NULL; pCurrent = pCurrent->next){
>   >      status=ca_change_connection_event(pCurrent->chan, myHandler);
>   >      SEVCHK(status, "ca_change_connection_event:
>   >      couldn't change handler");
>   >   }
>
> ca_change_connection_event() is normally used to replace an existing
> connection handler, which would have been initially associated with the
> channel by specifying it in the ca_search_and_connect() call used to open
> the channel.
>
ca_search_and_connect() was used at initialization with it returning
cs_conn before replacing it with ca_change_connection_event().

>   > and then have something like:
>   >
>   > while(1){
>   > 	ca_pend_event(POLL); //
>   > 	myGroupPoll();
>   > 	nanosleep(fiveseconds,NULL);
>   > }
>   >
>   > and then have my handler either block or remove from my list those
>   > channels that have been disconnected. Instead when I run it and
>   > disconnect a channel there is a pause of about 5 seconds and then a
>   > segmentation violation( although I think handler does get called).
>
> (The "pause" is probably the time it takes for your system to write out a
> "core" file.)
>
> What do you mean by "disconnect a channel" ?  Your connection handler has
> been invoked *because* the channel has changed connection state.  Either it
> has re-connected, or it is already disconnected.

I was speaking loosely. By disconnecting I meant I my ioc was rebooting.

>
>   > The same thing happens if I remove myGroupPoll().
>
> Which clearly implies that the action which causes the seg fault is in your
> connection handler.

I still see a seg fault if I replace myHandler with NULL or I just have
myHandler printing out the name of the channel via
ca_name(connect_args.chid). The name is printed correctly before aborting.

> If all you are doing in the connection handler is flagging when a channel
> is available or not, the CA library does that for you.  You only really
> need the connection handler if you need special handling (initialization,
> message generation, cleanup, etc) when the connection changes state.
> Otherwise, just test the state before you try to access the value.
>
Thanks for this info, you're right this is probably the better way to do
this.

Adam DeGrush



Replies:
Re: CA client library and Connection handler Brian McAllister
References:
Re: CA client library and Connection handler Brian McAllister

Navigate by Date:
Prev: Re: Epics 3.13.5 supporting Windows 2000 ? matthias muntwiler
Next: Re: et_wish, threadInit and osiThread.h Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  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 library and Connection handler Brian McAllister
Next: Re: CA client library and Connection handler Brian McAllister
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·