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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: Another gateway question |
From: | "Kevin Tsubota" <[email protected]> |
To: | "Jeff Hill" <[email protected]>, <[email protected]> |
Date: | Tue, 24 May 2011 16:48:48 -1000 |
Thank you Jeff. We have R3.14.12 but its for our
Solaris-10 servers only, for this server we’re stuck with Solaris-8 and
because of complier / make version issues I couldn’t get R3.14.12 to
build. Regarding the “network connection
lost” messages, it just continues to spew and the dbcar disconnect counts
just keep increasing. I’ve played with excas and it wasn’t
a problem accessing it from a separate test R3.13.10 VxWorks IOC. I even
created a gateway similar to what I have operationally with the only difference
being that my test setup is all on the same subnet. In my summit
environment, the R3.14.9 gateway runs on the main subnet serving a softIOC on a
private net and the vxworks IOC is on yet another subnet. When I get the system back I’m going
to try bypassing the gateway from my vxworks IOC by specifying the ipAddr:port in
its EPICS_CA_ADDR_LIST and see what happens… Thanks again. Kevin From: Jeff Hill [mailto:[email protected]] Hi Kevin, First I should
mention that a number of issues were fixed in the portable server
“cas” library for R3.14.11, and that the portable ca server library
is an significant component of the gateway. Some improvements were also made to
the gateway code itself at that time. In particular, the put callback
implementation, for gateways that permit writes, was substantially improved. http://www.aps.anl.gov/epics/base/R3-14/11-docs/RELEASE_NOTES.html I see that there are
two “Network Connection Lost” messages in the write-access-granted
output that you sent, and that dbcar also sees that all of the channels have
disconnected twice. Two disconnects is maybe a strange result unless this
number is reflecting the number of times that you restarted the gateway. If you
leave this running for awhile do you see that the number of disconnects, as
seen by dbcar is continuously increasing? Alternatively, does this number
increase each time that the gateway is restarted? If this number of disconnects
is always two soon after the IOC reboots, and isn’t increasing, then I
fear something is amiss with the R3.13 db ca link code or the ca client
library. It might help to type “i” in vxWorks, and then send the
output from “tt <task id>” for the db ca link thread, and the
ca client related threads that are running at close to the same priority. Ø
Is
it a vxworks / r3.13.x issue? Its probably more
likely to be an R3.13 issue than a vxWorks issue although I wasn’t aware
that there were any issues with R3.13 clients accessing the R3.14 portable CA
server library. Does your R3.13
camonitor/caget connect ok to the R3.14 excas (which uses the same ca server
library as the ca gateway)? A recent R3.14 CA reference manual will identify
what PVs are available in excas. You might also try placing a test record in
your R3.13 IOC which db ca links to an R3.14 excas. Jeff Message
content: TSPA With
sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925 From: [email protected]
[mailto:[email protected]] On
Behalf Of Kevin Tsubota I have another gateway issue, this
time its legit J
When the vxworks user doesn’t
have write access in the gateway I get the following output for the channels
behind the gateway: ( I cleaned up the output by
removing the good channels and you can ignore the not connected ones). ######################################################################## no write access ‘dbcar‘
summary: connected
k1laserserver:5064 no_read_access no_write_access k1:ao:ls:bpsd:lsshutCmd.OUT
k1:ao:ls:shutterCmd connected
k1laserserver:5064 no_read_access no_write_access k1:ao:ls:bto:btoTrack.OUT
k1:ao:ls:ss:btoperm nNoWrite 605 connected
k1laserserver:5064 no_read_access no_write_access k1:ao:ls:bpsd:lightOnPsd.INPB
k1:ao:ls:ss:PsdSum nNoWrite 0 connected
k1laserserver:5064 no_read_access no_write_access k1:ao:ls:bpsd:lsPropSt.INPA
k1:ao:ls:ss:LaserOn nNoWrite 0 connected
k1laserserver:5064 no_read_access no_write_access k1:ao:ls:bpsd:lsPropSt.INPB
k1:ao:ls:ss:LShutOpen nNoWrite 0 connected
k1laserserver:5064 no_read_access no_write_access k1:ao:ls:bto:pntState.INPA
k1:ao:ls:ss:OnSky nNoWrite 0 connected
k1laserserver:5064 no_read_access no_write_access k1:ao:ls:tm5psd:lsPropSt.INPA
k1:ao:ls:ss:LaserOn nNoWrite 0 connected
k1laserserver:5064 no_read_access no_write_access k1:ao:ls:tm5psd:lsPropSt.INPB
k1:ao:ls:ss:LShutOpen nNoWrite 0 connected
k1laserserver:5064 no_read_access no_write_access k1:ao:ls:bpsd:threshSel.NVL
k1:ao:ls:ss:FdMirState nNoWrite 0 connected
k1laserserver:5064 no_read_access no_write_access k1:ao:ls:tm5psd:threshSel.NVL
k1:ao:ls:ss:FdMirState nNoWrite 0 ncalinks 137 not connected 7
no_read_access 10 no_write_access 10 nDisconnect 0 nNoWrite 605 ######################################################################## When giving read/write access to the vxworks user, I get the
following errors and a different ‘dbcar’ output: read/write access dbcar summary: dbCa:exceptionCallback
stat "Network connection lost" channel "unknown" context
"k1laserserver:5064" nativeType
DBR_invalid requestType DBR_invalid nativeCount 0 requestCount 0 noReadAccess
noWriteAccess May 23,
2011 17:13:34.846100273 dbCa:exceptionCallback
stat "Network connection lost" channel "unknown" context
"k1laserserver:5064" nativeType
DBR_invalid requestType DBR_invalid nativeCount 0 requestCount 0 noReadAccess
noWriteAccess connected
k1laserserver:5064 k1:ao:ls:bpsd:lsshutCmd.OUT k1:ao:ls:shutterCmd nDisconnect
2 connected
k1laserserver:5064 k1:ao:ls:bto:btoTrack.OUT k1:ao:ls:ss:btoperm nDisconnect 2
nNoWrite 2668 connected
k1laserserver:5064 k1:ao:ls:bpsd:lightOnPsd.INPB k1:ao:ls:ss:PsdSum nDisconnect
2 nNoWrite 0 connected
k1laserserver:5064 k1:ao:ls:bpsd:lsPropSt.INPA k1:ao:ls:ss:LaserOn nDisconnect
2 nNoWrite 0 connected
k1laserserver:5064 k1:ao:ls:bpsd:lsPropSt.INPB k1:ao:ls:ss:LShutOpen
nDisconnect 2 nNoWrite 0 connected
k1laserserver:5064 k1:ao:ls:bto:pntState.INPA k1:ao:ls:ss:OnSky nDisconnect 2
nNoWrite 0 connected
k1laserserver:5064 k1:ao:ls:tm5psd:lsPropSt.INPA k1:ao:ls:ss:LaserOn
nDisconnect 2 nNoWrite 0 connected
k1laserserver:5064 k1:ao:ls:tm5psd:lsPropSt.INPB k1:ao:ls:ss:LShutOpen
nDisconnect 2 nNoWrite 0 connected
k1laserserver:5064 k1:ao:ls:bpsd:threshSel.NVL k1:ao:ls:ss:FdMirState
nDisconnect 2 nNoWrite 0 connected
k1laserserver:5064 k1:ao:ls:tm5psd:threshSel.NVL k1:ao:ls:ss:FdMirState
nDisconnect 2 nNoWrite 0 ncalinks 137 not connected 7
no_read_access 0 no_write_access 0 nDisconnect 20 nNoWrite 2668 ######################################################################## This crate is on a separate network
but I have the EPICS_CA_ADDR_LIST set to find the gateway which is using the
default EPICS_CA_SERVER_PORT. I’ve also logged into my unix
server as the vxworks user and it doesn’t have any problems accessing the
gateway channels. Only from vxworks. Is it a
vxworks / r3.13.x issue? Any thoughts on this would be
appreciated.
Kevin Tsubota WM
Keck Observatory |