Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Thu, 22 Apr 2010 16:34:03 -0500

Hi,

I think Andrew answered the question as to why the gateway changes things.

The "busy" record is important because it does not call recGblFwdLink until the value (Acquire in this case) goes back to 0, i.e. until the acquire is done.  This is critical for use in a data acquisition environment.  It allows the use of caPutCallback, where the callback will occur when the acquisition is complete.  This is needed by the EPICS sscan record and other applications that can scan arbitrary positioners and detectors without needing to poll to find out when they are done.

Mark

________________________________

From: [email protected] on behalf of Dennis Nicklaus
Sent: Thu 4/22/2010 11:40 AM
To: [email protected]
Cc: Denise Finstrom; Congcong Tan
Subject: gateway won't set "busy" PV type properly

We've encountered an odd behavior the last couple days that has us
pretty confused.
Can someone please explain this and/or suggest a fix?
When I set a certain PV going through an EPICS gateway, the setting
doesn't "work*" entirely.
If set through a non-gateway-ed connection, everything works fine.

By "work", I mean that it appears that the readback after a /caput
/fails.  The /caput /actually sets the valueof the PV (as we can see
from the intended effects happening), but the readback after the setting
fails.  On a terminal, it looks like this, where 13PS1:cam1:Acquire is
the PV name, Done is the ZNAM (value=0) and Acquire is the ONAM (value =1)./

/$ caget 13PS1:cam1:Acquire
13PS1:cam1:Acquire             Done
$ caput 13PS1:cam1:Acquire 1 
Old : 13PS1:cam1:Acquire             Done
Read operation timed out: PV data was not read.
New : 13PS1:cam1:Acquire            
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "op=0, channel=13PS1:cam1:Acquire, type=DBR_TIME_STRING,
count=1, ctx="cag-clx-2.fnal.gov:5064""
    Source File: ../getCopy.cpp line 86
    Current Time: Mon Apr 19 2010 16:07:57.274885243
..................................................................
$

(cag-clx-2.fnal.gov is the gateway computer.)
Inspection via caget shows that 13PS1:cam1:Acquire has indeed been set
to 1/Acquire.

Curiously, when we try to set this PV back to 0, the caput totally fails
-- it doesn't set the value and the readback fails.  That looks like this:

$ caput 13PS1:cam1:Acquire 0
Old : 13PS1:cam1:Acquire             Acquire
Read operation timed out: PV data was not read.
New : 13PS1:cam1:Acquire
CA.Client.Exception...............................................
  Warning: "Virtual circuit disconnect"
  Context: "op=0, channel=13PS1:cam1:Acquire, type=DBR_TIME_STRING,
count=1, ctx="cag-clx-2.fnal.gov:5064""
  Source File: ../getCopy.cpp line 86
  Current Time: Mon Apr 19 2010 16:09:33.470317689
..................................................................

$

The PV in this case comes from the Prosilica camera support package in
"areaDetector" version 1-6.  The PV 13PS1:cam1:Acquire is defined to be
a record type "busy" and basically turns on image acquisition:

record(busy, "$(P)$(R)Acquire") {
   field(DTYP, "asynInt32")
   field(OUT, "@asyn($(PORT),$(ADDR),$(TIMEOUT))ACQUIRE")
   field(ZNAM, "Done")
   field(ONAM, "Acquire")
}

Since we just picked up this camera support package recently, I don't
really know anything about the "busy" record type.  I did discover that
if I change it from "busy" to "bo" (binary output), everything works
fine and it will work through a gateway.  But of course, we're concerned
that we're losing whatever functionality/safety the original author
wanted from the "busy" type.

And in general, we're curious and confused as to why it acts differently
when it has to go through the gateway.  (If I set EPICS_CA_ADDR_LIST on
the requesting machine so that it bypasses the gateway, it works fine.)
Is it just some timeout because of the "busy" processing? Perhaps
someone can explain what the "busy" record type does that is so bad here?

More details:
The gateway s/w detects errors when it fails.
Errors in gateway logs:

Apr 22 09:26:50 !!! Errlog message received (message is above)
CAS Request: finstrom on clx32.fnal.gov: cmd=12 cid=2212591819 typ=0
cnt=0 psz=0 avail=1
CAS:
Apr 22 09:37:26 !!! Errlog message received (message is above)
bad resource id in "../../../../src/cas/generic/casStrmClient.cc" at
line 1706

backtrace from caput core file:

(gdb) bt
#0  0x00c6d402 in __kernel_vsyscall ()
#1  0x00530d20 in raise () from /lib/libc.so.6
#2  0x00532631 in abort () from /lib/libc.so.6
#3  0x004e82de in ca_client_context::vSignal (this=0x9172818,
ca_status=<value optimized out>, pfilenm=0x0, lineno=0,   
pFormat=0xb7e7ee68 "host=cag-clx-2.fnal.gov:5064 ctx=Bad Resource
ID=2212591819 detected at
../../../../src/cas/generic/casStrmClient.cc.1706", args=0xb7e7edd4 "J")
at ../ca_client_context.cpp:406
#4  0x004e8323 in ca_client_context::signal (this=0x9172818,
ca_status=410, pfilenm=0x0, lineno=0,    pFormat=0xb7e7ee68
"host=cag-clx-2.fnal.gov:5064 ctx=Bad Resource ID=2212591819 detected at
../../../../src/cas/generic/casStrmClient.cc.1706") at
../ca_client_context.cpp:358
#5  0x004e8709 in ca_client_context::exception (this=0x9172818,
guard=@0xb7e7f0a8, stat=410, pCtx=0xb7e7ee68
"host=cag-clx-2.fnal.gov:5064 ctx=Bad Resource ID=2212591819 detected at
../../../../src/cas/generic/casStrmClient.cc.1706",    pFile=0x0,
lineNo=0) at ../ca_client_context.cpp:314
#6  0x004c59e1 in cac::defaultExcep (this=0x9172a50, iiu=@0x91a3520,
pCtx=0x91a9040 "Bad Resource ID=2212591819 detected at
../../../../src/cas/generic/casStrmClient.cc.1706", status=410) at
../cac.cpp:909
#7  0x004c5802 in cac::exceptionRespAction (this=0x9172a50,
cbMutexIn=@0xb7e7f1c0, iiu=@0x91a3520, hdr=@0x91a36f4,
pMsgBdy=0x91a9030) at ../cac.cpp:1012
#8  0x004c55b5 in cac::executeResponse (this=0x9172a50, mgr=@0xb7e7f1c0,
iiu=@0x91a3520, currentTime=@0xb7e7f1c8, hdr=@0x91a36f4,
pMshBody=0x91a9030 "") at ../cac.cpp:1106
#9  0x004e07aa in tcpiiu::processIncoming (this=0x91a3520,
currentTime=@0xb7e7f1c8, mgr=@0xb7e7f1c0) at ../tcpiiu.cpp:1224
#10 0x004e0c5c in tcpRecvThread::run (this=0x91a35dc) at ../tcpiiu.cpp:530
#11 0x0021706e in epicsThreadCallEntryPoint (pPvt=0x91a35e0) at
../../../src/libCom/osi/epicsThread.cpp:42
#12 0x0021e65b in start_routine (arg=0x918d990) at
../../../src/libCom/osi/os/posix/osdThread.c:319
#13 0x00d3246b in start_thread () from /lib/libpthread.so.0
#14 0x005d8dbe in clone () from /lib/libc.so.6
(gdb)

We looked at the epics code where the error is. It appears to be a case
where it's trying to access a PV that doesn't exist.

Thanks for your help!
Dennis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System