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  <20082009  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  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Gateway problem .... more info
From: "Jeff Hill" <[email protected]>
To: "'Angelic Ebbers'" <[email protected]>, <[email protected]>
Date: Fri, 5 Sep 2008 16:49:42 -0600
> I'm seeing this effect on a large variety of records, from
> gensub records to some of our custom records (CAD, Apply, taskControl).
> I don't see any ca_put_callback delays on these records from the command
> line.  I'm increasingly confident that it must be a epics 3.12 to 3.14
> compatibility problem.

The timing and sequencing of the CA connect protocol is significantly
different in R3.12, and perhaps this has influenced a change in the behavior
of the gateway. The primary difference from the gateway's perspective is
that when the R3.14 client library is communicating with an R3.12 IOC the
latency from creation of the channel to receiving the first connect callback
is typically much shorter in contrast to the R3.14 client library's
communication with R3.13 and R3.14 IOCs.

Jeff Hill

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Angelic Ebbers
> Sent: Friday, September 05, 2008 2:22 PM
> To: [email protected]
> Subject: RE: Gateway problem .... more info
> 
> Hi,
> 
> 	I'm seeing this effect on a large variety of records, from
> gensub records to some of our custom records (CAD, Apply, taskControl).
> I don't see any ca_put_callback delays on these records from the command
> line.  I'm increasingly confident that it must be a epics 3.12 to 3.14
> compatibility problem.  I've managed to work around the problem by
> tweaking the gateway code to attempt to set the channel ready one more
> time if it attempts a write and the channel fails a ready check.  It
> looks like the initial ready check happens too quickly and some of the
> channels are taking longer to set up.  Then it doesn't attempt to set
> the channel ready again until an external get is called with "no_cache"
> set to true.
> 
> Cheers,
> Angelic
> 
> -----Original Message-----
> From: Dirk Zimoch [mailto:[email protected]]
> Sent: Friday, September 05, 2008 2:03 AM
> To: Angelic Ebbers
> Subject: Re: Gateway problem .... more info
> 
> Hi Angelic,
> 
> Do you write to one of those records that take a long time to complete a
> 
> ca_put_callback? Many SynApps records behave like that. For example the
> motor
> record does not become "ready" until motion has finished.
> 
> Dirk
> 
> Angelic Ebbers wrote:
> >>From studying the debugging logs, it looks like some channels
> > continuously report:
> > "write() pv not ready" when a client tries to write to them through
> the
> > gateway.
> > Then (usually triggered by a caget from a terminal) they become ready
> > "vcAdd() connecting -> ready"
> > After which a large backlog of writes are allowed through.
> >
> > In some cases, I looks like a write to an input field is put on hold
> as
> > the channel isn't "ready" and then when a write to the Directive field
> > goes through, the input field becomes ready and the input is written
> > after the directive ... causing the "out of order", and thus failed,
> > commands.
> >
> > What handshake between the ioc and the gateway is failing to set some
> > channels ready while others work properly?
> >
> > Some help here would be greatly appreciated.
> > Angelic
> >
> >
> 
> --
> Dr. Dirk Zimoch
> Paul Scherrer Institut, WBGB/006
> 5232 Villigen PSI, Switzerland
> Phone +41 56 310 5182


References:
Gateway problem .... more info Angelic Ebbers
RE: Gateway problem .... more info Angelic Ebbers

Navigate by Date:
Prev: RE: Gateway problem .... more info Angelic Ebbers
Next: RE: sseq link problem on Linux Shepherd, EL (Emma)
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Gateway problem .... more info Angelic Ebbers
Next: DBFLAGS in RULES.Db Allison, Stephanie
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  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 ·