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: "Paul Sichta" <[email protected]>
To: "Jeff Hill" <[email protected]>, <[email protected]>
Date: Thu, 3 Feb 2005 13:19:16 -0500
Jeff,
Most of your reasoning regarding caRepeater is explained in the CA Spec/manual, but I figured I was missing a build-switch that would include caClient-stuff with the app.


Later,
-ps



----- Original Message ----- From: "Jeff Hill" <[email protected]>
To: "'Paul Sichta'" <[email protected]>; <[email protected]>
Sent: Thursday, February 03, 2005 12:58 PM
Subject: RE: STATIC softIOC




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.


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


References:
RE: STATIC softIOC Jeff Hill

Navigate by Date:
Prev: RE: STATIC softIOC Jeff Hill
Next: RE: STATIC softIOC Ernest L. Williams Jr.
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 Jeff Hill
Next: RE: STATIC softIOC Ernest L. Williams Jr.
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 ·