Re: Does using "Constant Link Values" require using PINI=YES?

[Andrew Johnson via Tech-talk <tech-talk at aps.anl.gov>]

On 3/24/23 5:00 AM, Timo Korhonen via Tech-talk wrote:

Hi Érico,

P.S.: I couldn't find documentation that specified clearly that JSON links could be used in places like input links for "newer" EPICS
releases, outside of the release notes. That might be an interesting hole to plug in the docs. Would it go somewhere like [3]? I could try to
tackle it.

A good point, thank you for bringing this up.  The source file for [2] is in the Base distribution, modules/database/src/std/link/links.dbd.pod
in pod (Perl POD) format. In the build process, the document is auto-converted to HTML using some Perl scripts and libraries. 
Even if the file has the .dbd.pod extension, it is pure documentation and contains no dbd definitions or such.

Actually that last part isn't quite true, there are several link() declarations in that file outside of the Perl POD syntax which are essential to the IOC being able to use those declared link types, and a variable() declaration which is probably only needed for debugging the debug link type.

I see two alternatives:
1) as the text is rather "stable", i.e., has not and probably will not change a lot, integrating the text in [3], as you suggest.
2) I have an ambition to extend the build process a bit so that the pod file(s) would be processed and auto-included in RTD documentation, to be visible on docs.epics-controls.org.
However, option 2 has been progressing very slowly as my day job tends to take most of my time...

Integrating the description into [3] would make the usage clearer for users, so that might be the better (and right, IMO) option. 
The document is written and "owned" by Andrew Johnson, so I think he has the decisive vote.

You flatter me Timo, but no I didn't write and don't consider myself to be the owner of the "Process Database Concepts" document, although I have in the past helped revise and edit it to describe new functionality that was being added to the IOC. Unfortunately as Érico points out I did not actually do that when adding the extensible link support to the IOC, and I agree that this really should be described there, preferably using a reference to the specific link types that we document in the generated links.html file instead of explicitly describing them in the Concepts document.

I would suggest restructuring the Address Specification section of the the Concepts document slightly as I can see JSON link types as being more important in the future than the hard-coded hardware address types, so the Hardware Addresses part should probably appear later, and maybe the Constants section should come earlier too?

I'm very unlikely to have time in the next year or two to work on this myself other than review someone else's changes and perhaps explain the concepts, so I would be most happy for help from others in documenting the missing features.

- Andrew

But if we go for option 1 and you are willing to do the editing, please give it a go and make a pull request. It would then go to the docs site after review and merge.
Please let me know if you need instructions on how to proceed.

Best regards,

Timo


On 2023-03-23, 21:18, "Tech-talk on behalf of Érico Nogueira Rolim via Tech-talk" <tech-talk-bounces at aps.anl.gov <mailto:tech-talk-bounces at aps.anl.gov> on behalf of tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>> wrote:


Hello!




I am using Constant Link Values, as documented in [1], to initialize
some waveforms in my IOC. I'm defining my records as shown below:




record(waveform, "Array-Cte"){
field(FTVL, "LONG")
field(NELM, "4")
field(INP, [1,2,3,4])
}




However, when I use camonitor or pvget to receive their values, I am
notified that their values are, in fact, undefined/invalid:




$ pvget Array-Cte


Array-Cte <undefined> INVALID DRIVER UDF [1,2,3,4]




$ camonitor Array-Cte


Array-Cte <undefined> 4 1 2 3 4 UDF INVALID




If I add field(PINI, YES) to the record definition, I no longer get
notified about invalid values or anything. But it feels wrong to have to
add PINI in this case, since I'm declaring an initializer explicitly,
and it also feels ugly to leave the UDF/INVALID text in the output. Is
this expected behavior?




I am using epics-7 at the tip of master as of today
(5eff3803a83fbc3ea855b63841f5359c09830ade). This happens for waveforms
where FTVL is "STRING" as well, at the very least. It also happens if I
use the "{const: [1,2,3,4]}" syntax from [2].




[1] https://epics.anl.gov/base/R3-16/1-docs/RELEASE_NOTES.html <https://epics.anl.gov/base/R3-16/1-docs/RELEASE_NOTES.html>


[2] https://epics.anl.gov/base/R7-0/7-docs/links.html <https://epics.anl.gov/base/R7-0/7-docs/links.html>




Thank you,


Érico




P.S.: I couldn't find documentation that specified clearly that JSON
links could be used in places like input links for "newer" EPICS
releases, outside of the release notes. That might be an interesting
hole to plug in the docs. Would it go somewhere like [3]? I could try to
tackle it.




[3]
https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html <https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html>




Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.


Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.

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