EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  <19971998  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  <19971998  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: ioc re-connect problem
From: Alan K Biocca <[email protected]>
To: [email protected]
Date: Mon, 07 Apr 1997 08:56:29 -0700
We occasionally experience similar problems. I believe that Al Robb noticed
this behavior and did something in his sequencer to compensate. Not pretty.

I've suspected there are some subtle reconnect bugs, and we have spent time
on the beaconing system since it causes a similar problem - if beacons
aren't working correctly (like not getting through the router due to
misconfiguration), and connectivity is lost, rebooting an UNINVOLVED crate
can fix the problem since it causes all unconnected channels to be
re-searched.

The problem seems to be that unconnected channels give up at some point and
never retry. While that might be the desired behavior, I think I would set
the max-retry to a different value. Perhaps this is easily configurable in
some version, it didn't seem to be when we looked (3.12?). Since the retry
should only generate a broadcast packet (for the few unconnected channels)
every N minutes this would be acceptable for us. It would be nice to set
the 'global default' in the compile and be able to adjust the individual
client value in an environment variable. It should clamp to a minimum value
(say 1 minute) and a zero value would disable it (no retrys after initial
series).

-- Alan K Biocca
Advanced Light Source

At 04:16 PM 4/4/97 -0500, Chip Watson wrote:
>Here's a typical problem at Jefferson Lab (taken from log):
>
> The global sequence on iocin1 claimed the signals from iocin3 and iocwa4
> were monitored but not connected even though the iocs were indeed up and
> the signals reachable by caget.  iocin3 and iocwa4 also were not providing
> signals to iocin1.  The solution was to reboot iocin1 to force the se-
> quence to re-establish connections to various viewer iocs. Rebooting the
> data source (iocin3 or iocwa4) did not fix the problem.
>
>Anyone have any suggestions for how to find or fix this?
>
>Regards,
>
>Chip
>
>-----------------------------------------------------------------------------
>Chip Watson
>Internet: [email protected]    Thomas Jefferson National Accelerator Facility *
>Tel: (757) 269-7101          12000 Jefferson Avenue, MS 12A2
>FAX: (757) 269-5024          Newport News, VA 23606
>WWW: http://www.jlab.org/~watson/
>* (formerly CEBAF, the Continuous Electron Beam Accelerator Facility)
>
>

References:
ioc re-connect problem Chip Watson

Navigate by Date:
Prev: Re: Building a list of Channel ID's Marty Kraimer
Next: Re: cdev & CORBA Steve Hunt
Index: 1994  1995  1996  <19971998  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: ioc re-connect problem Chip Watson
Next: Re: ioc re-connect problem Jeff Hill
Index: 1994  1995  1996  <19971998  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 
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 ·