EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  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  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: STATIC softIOC
From: "Ernest L. Williams Jr." <[email protected]>
To: Jeff Hill <[email protected]>
Cc: "'Paul Sichta'" <[email protected]>, EPICS tech-talk <[email protected]>
Date: Thu, 03 Feb 2005 20:37:02 -0500
On Thu, 2005-02-03 at 10:58 -0700, Jeff Hill wrote:
> In past versions of EPICS, if the caRepeater executable could not be found,
> the repeater daemon process was created on POSIX by making a copy of the
> current process using the fork system call, but this has been a source of
> confusion and subtle problems (to put it mildly). With newer versions of
> EPICS this fall back behavior has been eliminated.
> 
> It is certainly possible for the repeater daemon to be implemented as an
> independent thread inside of the IOC process. This is in fact what is done
> on RTEMS and vxWorks. However, on process based OS this causes issues if an
> external CA client becomes dependent on this IOC resident CA repeater and,
> at some later time, the IOC containing the repeater is stopped. Given a weak
> cause and effect pattern of behavior and the likelihood that configuration
> decisions made in the past will not be remembered when adding additional
> clients to the same host in the future then I am inclined to conclude that
> an IOC resident CA repeaters would be an error prone and confusing option on
> process based OS. 
> 
> I am open to suggestions, but my current perspective is that, on process
> based OS, the CA repeater must be an independent process started from an
> independent executable.
> 
> The CA repeater's purpose is to receive CA server beacons and fan them out
> to all of the CA clients running in the same host. Most modern IP kernels
> now allow multiple listeners on the same UDP port, so that is no longer the
> reason for the CA Repeater. Unfortunately, there is still a defect in most
> IP kernels where UDP broadcasts reach multiple listeners on the same UDP
> port, but UDP unicasts (single host addressed datagrams) do not. Therefore,
> the CA repeater must still exist, and there can only be one of them on each
> host.
This is the case for process-based IOCs as well as vxWorks and RTEMS,
right?



> 
> Use of IP multicasts instead of IP broadcasts for CA beacons is something
> that could be considered for future versions. This might allow the CA
> repeater to be phased out.
> 
> Jeff
> 
> 
> > -----Original Message-----
> > From: Paul Sichta [mailto:[email protected]]
> > Sent: Thursday, February 03, 2005 9:49 AM
> > To: [email protected]
> > Subject: STATIC softIOC
> > 
> > Hi,
> > I'm trying to make a deployable, STATIC build of a soft IOC
> > application for Linux.  In base 3.14.7 I edited
> > configure/CONFIG to use STATIC=YES.  Then I made an
> > 'example' application using makeBaseApp.pl -t , then again
> > with -i -t.  Finally, I copied the app directory to another
> > Linux computer, which doesn't have base.
> > 
> > When I start the soft IOC task, AND when the database has an
> > INP field linked to a separate IOC, I get the warning "The
> > executable "caRepeater" couldn't be located", about a minute
> > later the IOC console displays "CA client library is unable
> > to contact CA repeater after 50 tries.", then no more
> > errors.  All the while the record with the INP link is
> > working.
> > 
> > Other than copying the base/bin and lib dirs to the target
> > machine and incorporating their paths, is there a method to
> > get the caRepeater (et al) included in the application's
> > bin/lib?  My old vxWorks IOC's have the caRepeater task
> > bundled in (somehow).
> > 
> > 
> > Thanks,
> > --
> > Paul Sichta
> > Princeton Plasma Physics Laboratory
> > 609-243-3477       FAX 3030
> 
> 


Replies:
RE: STATIC softIOC Jeff Hill
References:
RE: STATIC softIOC Jeff Hill

Navigate by Date:
Prev: Re: STATIC softIOC Paul Sichta
Next: PPT and PDF files of the presetation in EPICS meeting at TOKAI,JAPAN are now available on the web. Noboru Yamamoto
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: STATIC softIOC Paul Sichta
Next: RE: STATIC softIOC Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·