EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  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  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: gateway won't set "busy" PV type properly
From: Dirk Zimoch <[email protected]>
To: Dennis Nicklaus <[email protected]>
Cc: Denise Finstrom <[email protected]>, Congcong Tan <[email protected]>, [email protected]
Date: Fri, 23 Apr 2010 14:28:49 +0200
Hi Dennis,

I had similar problems with the motor record. Build the latest version of ca gateway with base 3.14.11 or higher and the problem should be fixed.

Starting from 3.14.11, the portable ca server, which is used in the gateway, is able to distinguish between put and put-callback requests. Before, the gateway always did put-callbacks, even if the client (e.g. medm) didn't. However, the motor record, the busy record and some other record types from synApps related to long-term actions (i.e. scans) don't sent the callback until the action they perform has finished (not when the action has successfully started as all the other records do). That blocked the gateway.

Dirk

Dennis Nicklaus wrote:
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 Dennis Nicklaus
References:
gateway won't set "busy" PV type properly Dennis Nicklaus

Navigate by Date:
Prev: problem with labview and epics zheng zheng
Next: Re: gateway won't set "busy" PV type properly Dennis Nicklaus
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: gateway won't set "busy" PV type properly Mark Rivers
Next: Re: gateway won't set "busy" PV type properly Dennis Nicklaus
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·