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. This file doesn’t document the “pva” link type though, which comes from the separate pva2pva module and is documented
as
part of QSRV. 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 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_nameThe 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.