Hi Andrew
Many thanks from my side, too. This really clarified a lot of things.
Large parts of what you wrote could and should be pasted into the
new EPICS documentation at https://docs.epics-controls.org.
Cheers
Ben
Am 26.03.20 um 19:39 schrieb Johnson, Andrew N. via Tech-talk:
> Okay, I need to apologize for using non-existent but potential link
> types in my examples when developing my proposals and documentation,
> they appear to have caused a fair bit of confusion – my intention was
> to show what could be possible in the future. Hopefully this rather
> long email will clarify the current state rather than confuse
> interested readers, in it I’m trying to answer all the points and
> questions raised up-thread.
>
> As a few people have pointed out, there are no “ca” or “db” link
> types available in current releases; anywhere you see those in
> documentation or on Wiki pages was just meant as potential examples,
> to show what might be possible. Actually the current API doesn’t let
> us create a “db” JSON link type yet because of the requirement for
> those links to join the two records involved into the same lock-set.
> There will be a Channel Access (“ca”) link type at some point, but it
> isn’t available yet (Michael started developing one but it has issues
> with locking when talking to local CA channels, so I suspect a
> different approach may be needed).
>
> The JSON link types that are available in your installation of EPICS
> Base from the core database module are documented in the file
> html/links.html that is installed during the build, or from the
> appropriate online version of
> that<https://epics.anl.gov/base/R7-0/3-docs/links.html>. This file
> doesn’t document the “pva” link type though, which comes from the
> separate pva2pva module and is documented as part of
> QSRV<https://epics-base.github.io/pva2pva/qsrv_page.html#qsrv_link>.
> Note that your IOC does need to be built with the qsrv.dbd file to be
> able to use “pva” links.
>
> As to Ben’s questions about what a record name is allowed to contain,
> this was one of my concerns when adding JSON links, and after
> consulting the core
> developers<https://epics.anl.gov/core-talk/2016/msg00160.php> and
> asking other community members at the SNS collaboration meeting, the
> IOC’s link field parser had to become stricter to be able to support
> them.
>
> It has never been the intention that record names may contain any
> unreserved character. Since Base-3.13.0 the Application Developers
> Guide has (in an admittedly slightly obscure location) documented
> which characters are supposed to be allowed in a record name. However
> because the IOC code didn't actually enforce any limitations when
> loading records, sites have been using characters in record names
> that go against what the documentation says for a long time. I have
> tried to avoid breaking those cases, but I can’t 100% guarantee that
> we won’t change things further in the future.
>
> In the last published version of the Application Developers Guide
> (for Base-3.16.2) section 6.4.11.2 says:
>
> record_name The record name. This must be composed out of only the
> following characters: a-z A-Z 0-9 _ - + : [ ] < > ;
>
>
> NOTE: If macro substitutions are used the name must be quoted.
>
> Note that the presence of quote characters and the $ sign make
> {db:"${SYS}:constFloatPi"} an invalid record name, and an EPICS 7 IOC
> will now print a warning message if it sees a space, single- or
> double-quote character, period or dollar sign in a record name (see
> dbRecordHead() in dbLexRoutines.c).
>
> When the IOC parses a link field value (dbParseLink() in
> dbStaticLib.c) it first strips any leading and trailing spaces, then
> if the string starts with ‘{‘ and ends with ‘}’ it is taken to be a
> JSON link address. The main user of brace characters in PV names that
> I could find at the time was NSLS-2, and their record names never
> match that pattern, so this rule doesn’t impact them. Similarly if
> the string starts with ‘[‘, ends with ‘]’ and contains at least one
> comma or double-quote character between those brackets, it is now a
> constant array. Only names that don’t match these and the older name
> tests can be parsed as record names in a DB or CA link.
>
> When parsing a JSON link string the dbLoadRecords() code only looks
> at the syntax of the JSON, so it’s possible to load a .db file that
> refers to a link tag such as “db” that doesn’t exist (or that hasn’t
> been registered with the IOC yet). Later on the iocInit() process
> will parse that link properly and won’t be able to find the requested
> link tag, so it will flag an error at that point.
>
> The example expression in the calc link documentation shows the use
> of a “db” link tag that doesn’t actually exist or work today, so calc
> links aren’t terribly useful at the moment since you can’t use the
> old-style DB/CA/CONST links in the “args” tag, only JSON link types
> (Ralph’s assumption that the calc link type was doing something
> special to support DB-links was unfortunately wrong, the
> documentation for the calc::args tag that Ben pointed to is correct
> so hopefully it doesn’t need any more clarification). I will change
> the example shown in the documentation to use a “pva” link instead.
>
> HTH,
>
> - Andrew
>
> -- Complexity comes for free, simplicity you have to work for.
>
________________________________
Helmholtz-Zentrum Berlin für Materialien und Energie GmbH
Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.
Aufsichtsrat: Vorsitzender Dr. Volkmar Dietz, stv. Vorsitzende Dr. Jutta Koch-Unterseher
Geschäftsführung: Prof. Dr. Bernd Rech (Sprecher), Prof. Dr. Jan Lüning, Thomas Frederking
Sitz Berlin, AG Charlottenburg, 89 HRB 5583
Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin
Attachment:
pEpkey.asc
Description: application/pgp-keys
- References:
- PV Access Rolf Keitel via Tech-talk
- Re: PV Access Johnson, Andrew N. via Tech-talk
- Re: PV Access Kivel Niko (PSI) via Tech-talk
- Re: PV Access Ralph Lange via Tech-talk
- Re: PV Access Ben Franksen via Tech-talk
- Re: PV Access Kivel Niko (PSI) via Tech-talk
- Re: PV Access Ralph Lange via Tech-talk
- Re: PV Access Ben Franksen via Tech-talk
- Re: PV Access Kivel Niko (PSI) via Tech-talk
- Re: PV Access Ralph Lange via Tech-talk
- Re: PV Access Johnson, Andrew N. via Tech-talk
- Navigate by Date:
- Prev:
Re: PV Access Kivel Niko (PSI) via Tech-talk
- Next:
Filtering messages print on the IOC shell console Paduan Donadio, Marcio via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: PV Access Kivel Niko (PSI) via Tech-talk
- Next:
Re: PV Access Marty Kraimer via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
|