Re: EPICS 7 array link inconsistencies

["Johnson, Andrew N. via Core-talk" <core-talk@aps.anl.gov>]

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

-- 
Complexity comes for free, Simplicity you have to work for.