Experimental Physics and Industrial Control System
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
- Replies:
- Re: gateway won't set "busy" PV type properly Andrew Johnson
- RE: gateway won't set "busy" PV type properly Mark Rivers
- Re: gateway won't set "busy" PV type properly Dirk Zimoch
- Navigate by Date:
- Prev:
Re: MAXv problem Ron Sluiter
- Next:
RE: Striptool crashes for Fedora 11 64 bit version... Kevin Anderson
- 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: EPICS Installation Mauro Giacchini
- Next:
Re: gateway won't set "busy" PV type properly Andrew Johnson
- 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