Experimental Physics and
Industrial Control System

All right, sorry Andrew, I missed the link statements in between the documentation. So maybe we leave the file and documentation together, which kind of rules out my alternative 1.

 

BTW, I meant that you are the author of the links.dbd.pod file (according to git commit history). The Process Database Concepts obviously has a more complicated history which I do not even know. I “rst’ified” it a couple of years ago, adding a few pieces about PVA links, etc. but otherwise did not change the contents a lot.

 

I think we can follow your suggestion of restructuring the DB Concepts and linking to the generated document. I should be able to use some of my time, and maybe Érico can make a proposal for the text. I have some ideas how to do the linking so that the content will be auto-generated in the CI builds.

 

Timo

 

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.