RE: Gateway problem .... more info

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

> 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: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov]
> On Behalf Of Angelic Ebbers
> Sent: Friday, September 05, 2008 2:22 PM
> To: tech-talk@aps.anl.gov
> 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:dirk.zimoch@psi.ch]
> 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