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
PATH=.:/home/epics/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:/usr/local/epics/base/bin/linux-x86_64:/usr/local/epics/epicsV4/EPICS-CPP-4.6.0/pvAccessCPP/bin/linux-x86_64:/usr/local/epics/extensions/bin/linux-x86_64
EPICS_BASE=/usr/local/epics/base
EPICS_EXTENSIONS=/usr/local/epics/extensions
EPICS_HOST_ARCH=linux-x86_64
EPICS_DISPLAY_PATH=/home/epics/adl/all
EPICS_IOC_LOG_FILE_NAME=/home/epics/logs/IOC.log
EPICS_IOC_LOG_FILE_LIMIT=10000000
EPICS_SUPPORT_PATH=/home/epics/support
EPICS_CA_MAX_ARRAY_BYTES=20000000
I am able to connect fine to any of the PVs in those 29 IOCs. 164.54.160.82 is the IP address of the machine running both the cainfo client and the IOCs.
corvette:busy/busyApp/src>cainfo 13IDC:m25
13IDC:m25
State: connected
Host: 164.54.160.82:41670
Access: read, write
Native data type: DBF_DOUBLE
Request type: DBR_DOUBLE
Element count: 1
Mark
> -----Original Message-----
> From: Church, Eric D [mailto:eric.church@pnnl.gov]
> Sent: Monday, December 04, 2017 12:48 PM
> To: Mark Rivers; Andrew Johnson; tech-talk@aps.anl.gov
> 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
> EPICS_CA_AUTO_ADDR_LIST=NO always.
>
> 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" <rivers@cars.uchicago.edu> 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: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> on behalf of
> Church, Eric D <eric.church@pnnl.gov>
> Sent: Friday, December 1, 2017 7:51 PM
> To: Andrew Johnson; tech-talk@aps.anl.gov
> 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=”192.168.1.255 5064, 192.168.1.255 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" <Jennifer.Mendez@pnnl.gov>
> Date: Friday, December 1, 2017 at 5:25 PM
> To: "Church, Eric D" <eric.church@pnnl.gov>
> Subject: iptables line
>
> https://wiki-
> ext.aps.anl.gov/epics/index.php/How_to_Make_Channel_Access_Reach_Multiple_Soft_IO
> 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
> 192.168.1.11
> arxe:/etc/NetworkManager/dispatcher.d$ echo $bcast
> 192.168.1.255
>
>
> On 11/9/17, 11:59 AM, "Andrew Johnson" <anj@aps.anl.gov> 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
>
>
>
>