EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: EPICS 7 array link inconsistencies
From: "Zimoch Dirk \(PSI\) via Core-talk" <[email protected]>
To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>
Date: Fri, 26 Jul 2019 15:03:57 +0000
On Wed, 2019-07-24 at 19:33 +0000, Johnson, Andrew N. via Core-talk wrote:
> Hi Dirk,
> 
> On 7/24/19 7:04 AM, Zimoch Dirk (PSI) via Core-talk wrote:
> > I found something confusing in the link syntax today when accessing arrays.
> > field(INP, "$(WF_RECORD).[5] CP") returns the number at index 5
> > but field(INP, "$(WF_RECORD).[5]") returns the number at index 0
> > 
> > This can be very confusing to the user. It would be nice to have the same array
> > syntax regardless of the link type, CA or not.
>  DB links do not currently support server-side filters, we never added them although it should be possible. Your .[5] is inserting an array filter into the CA channel used for the CA link, whereas the DB link is ignoring that filter spec (maybe the IOC should show a warning message if someone tries that).
> 
> If you wanted to take this on as a project I'd be happy to see it worked on. You would have to change the internals of the DB link to use a dbChannel instead of the current DBADDR, replacing calls to dbNameToAddr() with dbChannelCreate() and dbChannelOpen(). If a link's channel has any filters the dbDbGetValue() routine would have to call the dbChannelRunPreChain() and dbChannelRunPostChain() routines to execute them, and that would require creating a db_field_log to describe the source data for the filters to process.
> 
> If there are no filters you should short-circuit the new process and just use the existing approach, which will be much faster. I haven't thought about the other dbDbGet...() routines or how the dbDb_lset::doLocked() method might affect the above process — you'd want to only run the filter chain once if possible in this case; take a look at how the soft device support routines use dbLinkDoLocked() to fetch a value and timestamp through a link atomically in recent releases to understand how this method is used.
> 
> If you do decide to try this please let us know.
> 
> - Andrew
> 
Well..... That may take a while.
I was aware of the reason for the difference, but not of what needs to be done
to implement it. I will see what I can do.

Dirk


References:
EPICS 7 array link inconsistencies Zimoch Dirk (PSI) via Core-talk
Re: EPICS 7 array link inconsistencies Johnson, Andrew N. via Core-talk

Navigate by Date:
Prev: [Bug 1392516] Re: OSI monotonic time source Andrew Johnson via Core-talk
Next: normativeTypes module in EPICS 7.0.3 Johnson, Andrew N. via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: EPICS 7 array link inconsistencies Johnson, Andrew N. via Core-talk
Next: Jenkins build became unstable: epics-pva2pva-linux32 #126 APS Jenkins via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
ANJ, 26 Jul 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·