Hi Eric,
I should mention one thing.
If you have the following configuration:
- More than 1 network interface
- EPICS_CA_ADDR_LIST not set
- IOC running on the machine
- CA client (e.g. camonitor) on the same machine
then you should actually should receive warning messages each time your client connects to a PV. The warning will be that there are duplicates of that PV because each PV appears to be located on each of the network interfaces. The above configuration is actually what you have tried, but you were not seeing these warnings.
In order to avoid these warnings (once your current problem is solved) you need to tell the client to only search on one network interface by setting EPICS_CA_ADDR_LIST to the broadcast address of 1 (and only 1) network interface.
There is another solution in 3.15.4 and higher which is to configure the IOC with EPICS_CAS_INTF_ADDR_LIST rather than configuring the clients as above.
I would suggest that you should try this:
- Unset EPICS_CA_ADDR_LIST and EPICS_CA_AUTO_ADDR_LIST
- Make sure all firewalls are disabled. I believe the firewall can block even local clients, though I am not sure about that.
I guess another obvious test under those conditions is to see if you can access the PVs from another machine. You should be able to. If you can, but still cannot access them from the local machine that will tell us something.
Mark
________________________________
From: Church, Eric D <[email protected]>
Sent: Tuesday, December 5, 2017 9:33 PM
To: Mark Rivers; 'Kasemir, Kay'; Ralph Lange; EPICS Tech Talk
Cc: Mendez, Jennifer M
Subject: Re: caget() from C++
So, indeed, the warnings go away when I set EPICS_CA_AUTO_ADDR_LIST=NO. However, no matter if I use my eth0 or eth1 broadcast address, I can not use camonitor on either set of IOC’s PVs.
Along these lines, I tried to read Kay’s 2012 post (http://www.aps.anl.gov/epics/tech-talk/2012/msg02356.php), that motivated the following effort:
I tried firing up IOC1 with EPICS_CA_ADDR_LIST=eth0bcast:5065, EPICS_CA_ PORT=5065 and IOC2 with EPICS_CA_ADDR_LIST=eth0bcast:5066, EPICS_CA_ PORT=5066, and in the session where I run camonitor I say EPICS_CA_ADDR_LIST=” eth0bcast:5066”. I also tried it with eth0->eth1.
camonitor fails when I do this, and CSS and archive-engine do also. Only, it seems, if I set EPICS_CA_ADDR_LIST=localhost can I use camonitor, and only then on the PVs of the second IOC that I fire up.
What is so non-standard about my network on this everything-on-one-computer setup of mine? Does a firewall even matter in this case?
- Eric
On 12/5/17, 2:45 PM, "Mark Rivers" <[email protected]> wrote:
If you set the EPICS_CA_ADDR_LIST to the broadcast address then you must also set EPICS_CA_AUTO_ADDR_LIST=NO. That is why you are getting these warnings, because these broadcast addresses were already being used because EPICS_CA_AUTO_ADDR_LIST was defaulting to YES.
Warning: Duplicate EPICS CA Address list entry "192.168.1.255:5064" discarded
Warning: Duplicate EPICS CA Address list entry "130.20.49.255:5064" discarded
> -----Original Message-----
> From: Church, Eric D [mailto:[email protected]]
> Sent: Tuesday, December 05, 2017 4:06 PM
> To: Mark Rivers; 'Kasemir, Kay'; Ralph Lange; EPICS Tech Talk
> Cc: Mendez, Jennifer M
> Subject: Re: caget() from C++
>
>
> I attach a file showing my efforts at setting this variable in the xterm session in which I run
> my caxyz commands and the record of my puzzling problems. Before trying to export these
> values of EPICS_CA_ADDR_LIST, all was well. Whereas, after setting it, failingx2, if I
> unset it I can not connect: I am not returning to successful camonitoring of just even one
> IOC.
>
> Note: all the relevant-looking complaints from my 2nd IOC terminal in the attached file ….
>
> - Eric
>
>
>
> On 12/5/17, 1:43 PM, "Mark Rivers" <[email protected]> wrote:
>
> > Looks like the EPICS_CA_ADDR_LIST used by camonitor is not using the broadcast
> address of your host.
>
> It should be doing that automatically without you needing to set
> EPICS_CA_ADDR_LIST. Can you send the output of the following commands Linux
> command in the shell where you are running camonitor.
>
> ifconfig
> printenv | grep EPICS
>
> At the IOC shell prompt on both the first and second IOCs send the output of
>
> epicsPrtEnvParams
>
>
> What happens if you set EPICS_CA_ADDR_LIST manually to the broadcast address of
> your system? For example on my system ifconfig shows:
>
> p5p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> inet 164.54.160.82 netmask 255.255.255.0 broadcast 164.54.160.255
> inet6 fe80::3efd:feff:fea3:f258 prefixlen 64 scopeid 0x20<link>
> ether 3c:fd:fe:a3:f2:58 txqueuelen 1000 (Ethernet)
> RX packets 80276465019 bytes 92598173910474 (84.2 TiB)
> RX errors 0 dropped 114 overruns 0 frame 0
> TX packets 32261858165 bytes 16671972218313 (15.1 TiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>
> So I would set EPICS_CA_ADDR_LIST=164.54.160.255
>
> Mark
>
>
>
>
> > -----Original Message-----
> > From: Kasemir, Kay [mailto:[email protected]]
> > Sent: Tuesday, December 05, 2017 3:37 PM
> > To: Church, Eric D; Mark Rivers; Ralph Lange; EPICS Tech Talk
> > Cc: Mendez, Jennifer M
> > Subject: Re: caget() from C++
> >
> > >Indeed camonitor can properly watch a channel on the first IOC when only it is
> running. I
> > can dial up and down the voltage from CSS on a particular PV on this first IOC and
> watch
> > it move on camonitor. >When I start the second IOC I can continue this exercise on
> POVs
> > on the first IOC. If I kill camonitor, per your suggestion, I can not start it again on a PV
> on
> > the first IOC. And if I kill the second IOC I can >once again start camonitor
> successfully on
> > a PV on the first IOC.
> >
> > >What does it mean, do ya think?
> >
> > Looks like the EPICS_CA_ADDR_LIST used by camonitor is not using the broadcast
> > address of your host.
>
>
>
- 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
- Re: caget() from C++ Mark Rivers
- 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
- Re: caget() from C++ Church, Eric D
- Re: caget() from C++ Mark Rivers
- Re: caget() from C++ Ralph Lange
- Re: caget() from C++ Mark Rivers
- Re: caget() from C++ Church, Eric D
- Re: caget() from C++ Kasemir, Kay
- RE: caget() from C++ Mark Rivers
- Re: caget() from C++ Church, Eric D
- RE: caget() from C++ Mark Rivers
- Re: caget() from C++ Church, Eric D
- Navigate by Date:
- Prev:
Re: caget() from C++ Church, Eric D
- Next:
RE: EPICS 7 Release Candidate 1 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
<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
|