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: [email protected] <[email protected]> on behalf of Church, Eric D <[email protected]>
Sent: Friday, December 1, 2017 7:51 PM
To: Andrew Johnson; [email protected]
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" <[email protected]>
Date: Friday, December 1, 2017 at 5:25 PM
To: "Church, Eric D" <[email protected]>
Subject: iptables line
https://wiki-ext.aps.anl.gov/epics/index.php/How_to_Make_Channel_Access_Reach_Multiple_Soft_IOCs_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" <[email protected]> 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
- Replies:
- Re: caget() from C++ Church, Eric D
- References:
- caget() from C++ Church, Eric D
- Re: caget() from C++ Andrew Johnson
- Re: caget() from C++ Church, Eric D
- Navigate by Date:
- Prev:
Re: caget() from C++ Church, Eric D
- Next:
Set the PV value in different interface through script xus
- Index:
1994
1995
1996
1997
1998
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:
Re: caget() from C++ Church, Eric D
- Next:
Re: caget() from C++ Church, Eric D
- Index:
1994
1995
1996
1997
1998
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
|