Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018 
<== Date ==> <== Thread ==>

Subject: Re: caget() from C++
From: "Church, Eric D" <>
To: Mark Rivers <>, Andrew Johnson <>, "" <>
Cc: "Mendez, Jennifer M" <>
Date: Mon, 4 Dec 2017 20:40:15 +0000
Hi, Mark:

Unsetting EPICS_CA_AUTO_ADDR_LIST and restarting IOCs and using cainfo again makes no difference.

Can I ask how your cainfo knows to look on for PVs if  you’ve indeed unset all these environment variables? And also, can you show cainfo output for a different PV that will be discovered on a different port than 41670?

I do not understand (at least) one thing: why does my first process use port 5064? I thought it may’ve been a build-time environment setting, but I just rebuilt the code with these variables all unset, and again, the first IOC uses the port 5064. The next IOC, as previously, knocks that one out and connects on another port.

Do you recommend any diagnostics I might do with netstat or some other port tool?

- Eric 

On 12/4/17, 11:48 AM, "Mark Rivers" <> wrote:

    Hi Eric,
    If you unset EPICS_CA_ADDR_LIST you must also unset EPICS_CA_AUTO_ADDR_LIST=NO.
    If you do that then it should work.  Here are the results on my Linux system, which is running 29 IOCs.
    Note that neither EPICS_CA_ADDR_LIST nor EPICS_CA_AUTO_ADDR_LIST are set:
    corvette:busy/busyApp/src>printenv | grep EPICS
    I am able to connect fine to any of the PVs in those 29 IOCs. is the IP address of the machine running both the cainfo client and the IOCs.
    corvette:busy/busyApp/src>cainfo 13IDC:m25
        State:            connected
        Access:           read, write
        Native data type: DBF_DOUBLE
        Request type:     DBR_DOUBLE
        Element count:    1
    > -----Original Message-----
    > From: Church, Eric D []
    > Sent: Monday, December 04, 2017 12:48 PM
    > To: Mark Rivers; Andrew Johnson;
    > Cc: Mendez, Jennifer M
    > Subject: Re: caget() from C++
    > Hi, Mark:
    > Yes, this is our configuration, and everything is on one computer. My only client process for
    > now is cainfo.
    > Disabling iptables has no effect.
    > I just tried your advice to unset both those EPICS envt variables
    > EPICS_CA_SERVER_PORT and EPICS_CA_ADDR_LIST and restart the IOCs. For me
    > After I do this, in another terminal with those envt variables also as above I can try cainfo.
    > This fails, with cainfo complaining about not knowing what machine to look on; I seem to
    > need to  set EPICS_CA_ADDR_LIST=localhost at least. If I do this I see my IOC is
    > connected on port 5064 and can happily interrogate PVs. As soon as I fire up my next IOC,
    > after a couple seconds, a cainfo shows my first IOC no longer has a port number after some
    > delay. It can retrieve no PVs. My newest IOC is happily running on a port like 36444 (some
    > 5-digit number, usually), and cainfo now happily retrieves its PVs. If I restart IOCs in the
    > other order, I get the symmetric result. The second one started works on some new high-
    > numbered port and the first one which had been on 5064 is disconnected as far as cainfo
    > can see. It may be interesting to note that if I kill my IOCs and restart one of ‘em, after
    > trying to set EPICS_CA_SERVER_PORT=36444 (say) cainfo fails to find the connected
    > PVs even for just this one running IOC.
    > - Eric
    > On 12/2/17, 6:07 AM, "Mark Rivers" <> wrote:
    >     Do I understand that you have the following configuration:
    >     - 2 IOCs running on the same host
    >     - No PV Gateway running
    >     - You want to access the PVs on the 2 IOCS from IOC computer itself or from other
    > computers on the same subnet
    >     If so, that is a very common configuration.  It should work fine with no special setting of
    > EPICS_CA_ADDR_LIST or EPICS_CA_AUTO_ADDR_LIST.  Unset both of those
    > environment variables, both for client processes and for the IOC server processes.
    >     If you suspect the problem is due to iptables then have you tried temporarily disabling
    > iptables and seeing if that fixes it?
    >     Mark
    >     ________________________________
    >     From: <> on behalf of
    > Church, Eric D <>
    >     Sent: Friday, December 1, 2017 7:51 PM
    >     To: Andrew Johnson;
    >     Cc: Mendez, Jennifer M
    >     Subject: Re: caget() from C++
    >     Hi, Andrew:
    >     Eric here again. We (my colleague Jen, actually) indeed solved our last problem with
    > ca_put and ca_get in threaded C++. We’re happily connecting and reading/writing from/to
    > our IOC now. Many thanks for the help.
    >     Our next problem is that we now have two identical power supplies on same localhost we
    > need to do this with. We see we’re not the only ones to have come across this issue where
    > starting up the second IOC makes cainfo calls to the first one not work. The channels are
    > uniquely named and the IOCs successfully connect to the HVCAEN and appear to be
    > running. However, cainfo to PVs on the second IOC work and report a 5-digit port number
    > that it’s using, while the first IOC, which had been working fine on 5064 is suddenly
    > disconnected. We tried following the instructions from your link below to change the
    > iptables routing. /var/log/messages doesn’t complain, but nothing from subsequent iptables
    > commands confirms to us that the instruction actually took hold. And the cainfo behavior
    > does not change after IOC restarts. We also tried, per Kay’s instructions somewhere,
    > changing EPICS_CA_ADDR_LIST=” 5064, 5064” from it’s
    > former value of NO, which didn’t help
    >     Do you have a nudge that can get us past this problem?
    >     Thx -- Eric
    >     From: "Mendez, Jennifer M" <>
    >     Date: Friday, December 1, 2017 at 5:25 PM
    >     To: "Church, Eric D" <>
    >     Subject: iptables line
    >     https://wiki-
    > Cs_on_a_Linux_Host#On_RedHat_and_Derivatives
    >     arxe:/etc/NetworkManager/dispatcher.d$ sudo  /sbin/iptables -t nat -A PREROUTING -d
    > $addr -p udp --dport 5064 -j DNAT --to-destination $bcast
    >     arxe:/etc/NetworkManager/dispatcher.d$ echo $addr
    >     arxe:/etc/NetworkManager/dispatcher.d$ echo $bcast
    >     On 11/9/17, 11:59 AM, "Andrew Johnson" <> wrote:
    >         Hi Eric,
    >         On 11/08/2017 10:05 AM, Church, Eric D wrote:
    >         > We are trying to use caput() and caget() from a C++ program. The IOC is
    >         > up and I can issue caputs and cagets from the command line and put and
    >         > retrieve reasonable values into our EPICS records. We’re having some
    >         > difficulty in compiled C++, however.
    >         >
    >         > I include below the apparently necessary gymnastics to successfully
    >         > ca_get() anything in C++. We want to do this with a total of about 48
    >         > PVs once every 15 seconds. The first thing we note is we need to do a
    >         > context_create and create_channel each of those 48 times each 15
    >         > seconds. Which necessitates the channel clear and context destroy at the
    >         > end. We can not use our class member chid over and over with each run
    >         > through this function, it seems.
    >         I want to make sure I understand your requirements first: Is the problem
    >         you describe (that you continually have to create and destroy channels)
    >         because your application is structured such that you don't have a single
    >         long-running process, or because you're having problems coding it to
    >         keep all those channels connected?
    >         For efficiency reasons it is much better to connect everything once and
    >         keep the connection to the IOC(s) open all the time, re-useing the same
    >         chids every time you want to do some more I/O. You do have to make sure
    >         that your client code can cope with the IOC shutting down, rebooting or
    >         not being turned on until some time after the client has been started,
    >         but that is generally just a matter of getting the code right.
    >         Unfortunately our standard CA client code examples only really show the
    >         quick-and-dirty approach of connecting channels, doing some I/O and then
    >         shutting down again almost immediately. When you're writing a long-lived
    >         client though you should generally only use the CA APIs that use
    >         callbacks to notify you when the client library gets messages from the
    >         IOC servers it's connected to. The ca_pend_io() routine is not suitable
    >         for this style of programming, where your code generally consists of
    >         routines that react to events from outside and work out what to do next.
    >         It is legal to call most CA routines from within a callback (the CA
    >         reference manual describes the 2 or 3 routines where that is not
    >         allowed, ca_pend_io() being one of them).
    >         I think I'm going to stop here and wait for your reply to the above
    >         question before I write any more or review the code you posted.
    >         - Andrew
    >         --
    >         Arguing for surveillance because you have nothing to hide is no
    >         different than making the claim, "I don't care about freedom of
    >         speech because I have nothing to say." -- Edward Snowdon

RE: caget() from C++ Mark Rivers
caget() from C++ Church, Eric D
Re: caget() from C++ Andrew Johnson
Re: caget() from C++ Church, Eric D
Re: caget() from C++ Mark Rivers
Re: caget() from C++ Church, Eric D
RE: caget() from C++ Mark Rivers

Navigate by Date:
Prev: RE: caget() from C++ Mark Rivers
Next: RE: caget() from C++ Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018 
Navigate by Thread:
Prev: RE: caget() from C++ Mark Rivers
Next: RE: caget() from C++ Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018 
ANJ, 21 Dec 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·