EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: dbGetLink question
From: Mark Rivers <[email protected]>
To: 'Andrew Johnson' <[email protected]>, "[email protected]" <[email protected]>
Date: Fri, 1 Dec 2017 16:40:42 +0000
Hi Andrew,

Thanks for the reply:

> I don't want to encourage this usage which is why I've never documented it myself,

Can you explain what you mean by "this usage"?  You mean relying on the fact that dbGetLink establishes monitor on CA links for both input and output?

The problem is that the Developer's Guide is currently just silent on the topic, but it is important.

It currently says the following:

**************************************************
- At IOC initialization, dbCa issues channel access search requests for each channel access link.

- For each input link it establishes a channel access monitor, using the channel’s native field type and element
count. It also monitors the alarm status. Whenever the monitor callback gets invoked the new data is stored in a
buffer belonging to dbCa. When iocCore or the record support module asks for data from the link, the contents
of the buffer are converted to the requested type.

- For each output link, a buffer is allocated the first time iocCore/record support issues a put after the channel
access connection has been made. This buffer is allocated large enough to store the channel’s native field type
and element count Each time iocCore/record support issues a put, the data is converted and placed in the buffer
and a request is made to dbCa to issue a new ca_put.
**************************************************

This provides no information how dbGetLink will work on output links, leading to the question I posted.  Why not say that it also establishes monitors on output links?

This question was prompted by the recent thread on the EPID record (http://www.aps.anl.gov/epics/tech-talk/2017/msg01863.php).  I was wondering whether the "bump" that was being seen could be caused by dbGetLink not working for the output link if it was CA.  It sounds from your description like that should not be a problem, as long as it was not the first time that dbGetLink was called for that link.  But if I had known how it works I would have done a dbGetLink at iocInit to be sure it did not fail the first time.

Thanks,
Mark


> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Andrew Johnson
> Sent: Friday, December 01, 2017 10:26 AM
> To: [email protected]
> Subject: Re: dbGetLink question
> 
> Hi Mark,
> 
> On 12/01/2017 08:47 AM, Mark Rivers wrote:
> >
> > I have a question about how dbGetLink works.  I have read the
> > Application Developer's Guide (3.15.5) but it is not clear.
> > Specifically I want to understand how it works under the following
> > conditions:
> >
> > - Link is an output link
> > - Link process type is CA
> > - The output PV resides in another IOC.
> >
> > Does dbGetLink actually read the value from the other IOC?  It
> > seems like that would be a slow operation, and so would require
> > the record to be asynchronous?  Or does the database put a
> > camonitor on that external record so the link value can be
> > obtained without an actual caget operation?  If so, I cannot
> > find this mentioned in the Application Developer's Guide.  It
> > only describes channel access monitors being set up for input
> > links, not output links.
> 
> Please be aware that in Base 3.16.1 we introduced extensible link types
> so things have changed under the hood in future releases, but the use
> case you are describing will still work for CA links. I don't want to
> encourage this usage which is why I've never documented it myself, but
> it has been used enough (mostly in subroutine record routines) that
> breaking this now would cause problems for a number of sites. It also
> works for DB links, but isn't guaranteed for future link types.
> 
> At IOC initialization, all CA links are passed to the CA client library
> and a chid created for them by the dbCa code. Then the first time a
> record type calls dbGetLink() on such a CA link (whether it's an input
> or output link) dbCa sets up a monitor for that request, but doesn't
> actually return a value yet. Future dbGetLink() calls will return values
> from the latest monitor event they received.
> 
> HTH,
> 
> - Andrew
> 
> --
> Arguing for surveillance because you have nothing to hide is no
> different than making the claim, "I don't care about freedom of
> speech because I have nothing to say." -- Edward Snowdon

Replies:
Re: dbGetLink question Andrew Johnson
References:
dbGetLink question Mark Rivers
Re: dbGetLink question Andrew Johnson

Navigate by Date:
Prev: Andor shamrock not detected Hinko Kocevar
Next: RE: Andor shamrock not detected Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: dbGetLink question Andrew Johnson
Next: Re: dbGetLink question 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  <20172018  2019  2020  2021  2022  2023  2024