EPICS Home

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  2019  2020  2021  2022  2023  2024  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  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: caget() from C++
From: "Church, Eric D" <[email protected]>
To: Mark Rivers <[email protected]>, Andrew Johnson <[email protected]>, "[email protected]" <[email protected]>
Cc: "Mendez, Jennifer M" <[email protected]>
Date: Tue, 5 Dec 2017 02:56:39 +0000
Hi, Mark:

I attach a screenshot of my netstat –anp’ing after getting both IOC’s up. I grep separately for the ports in use: 5064 and the non-5064 one. I also grep for the “bin/lin” string just to show those are my  2 running IOCs. The two java processes are my archive-engine and CSS. I do note that I have 2 extra UDP listings for the port 5064. 

(1) Do you see these extra 2 UDP listings for the default port too?
(2) I am not sure why I have entries for the 130.20.x.y interface, even though I’m entirely contained on one computer and thought I’d only see traffic on 127.0.0.1.
(3) I point out my CSS is fine. Sometimes it can not see the PVs on the IOC that I can also not cainfo into, but a restart of the IOC fixes that, and CSS is fully functional to monitor and control all my PVs.  
(4) My archive-engine is also fine. It tells me all my PVs are connected. If I call the IOC they disconnect of course, but restarting the IOCs brings back the connection.
(5) cainfo still does not see the PVs on 5064 port.
(6) My other client that does the ca_get() and ca_put() in C++ also has the problem of (4). This is the only reason I care about this. Cuz otherwise I have good functionality.
(7) If I kill my archive-engine and my CSS I have fewer entries from netstat, but the same behavior: 2 extra UDP connections reported for 5064, and I can not talk to those PVs with cainfo.

Thanks for anything you can share about how netstat looks on your node(s).

Thx -- Eric

On 12/4/17, 12:54 PM, "Mark Rivers" <[email protected]> wrote:

    > Can I ask how your cainfo knows to look on 164.54.160.82 for PVs if  you’ve indeed unset
    > all these environment variables? 
    
    By default CA searches on the broadcast address of all network interfaces.  So without the environment variables set it will work on "typical" configurations, i.e. where all the PVs are on the local subnet.
    
    > And also, can you show cainfo output for a different PV
    > that will be discovered on a different port than 41670?
    
    Here are 2.  This appears to be the first IOC that was started, since it is using port 5064
    
    corvette:~/devel>cainfo 13BMD:m91
    13BMD:m91
        State:            connected
        Host:             164.54.160.82:5064
        Access:           read, write
        Native data type: DBF_DOUBLE
        Request type:     DBR_DOUBLE
        Element count:    1
    
    Here is another using a different port.
    
    corvette:~/devel>cainfo 13IDD:m81
    13IDD:m81
        State:            connected
        Host:             164.54.160.82:40532
        Access:           read, write
        Native data type: DBF_DOUBLE
        Request type:     DBR_DOUBLE
        Element count:    1
    
    > I do not understand (at least) one thing: why does my first process use port 5064? 
    
    That is the default.
    
    > 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.
    
    The next should use a different port but is should not "knock out" the first.  They should both be running.
    
    Is it possible that you have the subnet mask on your system set wrong?  Just grasping at straws here.
    
    Mark
    
    
    > -----Original Message-----
    > From: Church, Eric D [mailto:[email protected]]
    > Sent: Monday, December 04, 2017 2:40 PM
    > To: Mark Rivers; Andrew Johnson; [email protected]
    > Cc: Mendez, Jennifer M
    > Subject: Re: caget() from C++
    > 
    > 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 164.54.160.82 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" <[email protected]> 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
    > 
    > PATH=.:/home/epics/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:/usr/local/epics/base/bin/li
    > nux-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:[email protected]]
    >     > Sent: Monday, December 04, 2017 12:48 PM
    >     > To: Mark Rivers; Andrew Johnson; [email protected]
    >     > 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" <[email protected]> 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: [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_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" <[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
    >     >
    >     >
    >     >
    >     >
    > 
    > 
    
    

Attachment: Screenshot-1.png
Description: Screenshot-1.png


Replies:
Re: caget() from C++ Mark Rivers
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

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  2019  2020  2021  2022  2023  2024 
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  2019  2020  2021  2022  2023  2024