RE: Another gateway question

["Jeff Hill" <johill@lanl.gov>]

Ø  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.  

 

So since your R3.13.10 IOC doesn’t have any troubles with the R3.14 excas then perhaps we can conclude that there aren’t any CA protocol level issues with R3.13.10 CAC ó R3.14 PCAS. Is your excas in the test based on R3.14.10 or R3.14.12?

 

Ø   

Ø  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.

 

Perhaps you can run the same excas test on the summit during daylight hours – where excas temporarily runs on the same system as the gateway?

 

Ø  Regarding the “network connection lost” messages, it just continues to spew

Ø  and the dbcar disconnect counts just keep increasing.

 

The client library will periodically disconnect the application if it doesn’t see beacons from the server (in this case the gateway), and the server isnt responsive to an are-you-there request over tcp. So its conceivable that your periodic disconnect occurs because of a marginal network connection. Admitedly, that doesn’t explain why it works differently when changing the access rights. Do the disconnects occur periodically every EPICS_CA_CONN_TMO (defaulting to 30.0) seconds? Does the system running the gateway have an unusually high CPU load? Does the R3.13 IOC have a high CPU load?

Jeff
______________________________________________________
Jeffrey O. Hill           Email        johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

 

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: Kevin Tsubota [mailto:ktsubota@keck.hawaii.edu]
Sent: Tuesday, May 24, 2011 8:49 PM
To: Jeff Hill; tech-talk@aps.anl.gov
Subject: RE: Another gateway question

 

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:johill@lanl.gov]
Sent: Tuesday, May 24, 2011 1:16 PM
To: Kevin Tsubota; tech-talk@aps.anl.gov
Subject: RE: Another gateway question

 

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
______________________________________________________
Jeffrey O. Hill           Email        johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

 

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: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Kevin Tsubota
Sent: Tuesday, May 24, 2011 11:47 AM
To: tech-talk@aps.anl.gov
Subject: Another gateway question

 

I have another gateway issue, this time its legit J

My EPICS clients (caget, caput, camonitor and guis) can access my PVs behind my gateway (R3.14.9).  However, I have a MVME2304 running VxWorks 5.3.1 and EPICS R3.13.10 and it’s having issues with the gateway, basically its not connecting.  Before I added the gateway, it was directly accessing the channels in question via EPICS_CA_ADDR_LIST and it didn’t have any issues.

 

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.

Mahalo!

Kevin Tsubota

WM Keck Observatory