In this document, the INST_IO format is like that:
#@parm
but if you put the '#' at the beginning, the INST_IO address will be read as empty string.
Am I miss anything?

The installation instructions for Linux recommend using git clone to fetch the source code from the default branch, which isn't really a good idea as it might be in the middle of a transition so could be broken. I think they should show new users how start from a release tar-file first, like the Windows instructions do.

See epics-base/epics-base#266 for details.

As we are recommending markdown as default format (file:///home/gabrielfedel/events/EPICSDocumentathon2023/epics-docs/build/html/CONTRIBUTING.html#style-guide) it would be good to have all the documents on that format.

Suggestion of tool to help on that: https://pandoc.org/

The EPICS documentation on RTD should have a top page for the C/C++ releases, versioned on the release, that contains the documentation of base (and links to the appropriate versions of module documentation).

Note : I am referring to how-to "EPICS Installation on Windows". This guide "https://github.com/epics-docs/how-tos" is shifted to new location "https://github.com/epics-docs/epics-docs". I hope, I am at right location.

There are recommended or minimum versions of software components which should be used for this procedure to work. But, I would like to add software stack information in this procedure for which we have tested it and known to be working, As I am getting query related to the versions of the component I used for verification.

Example,

1. Software Stack for Plain windows,

• Visual Studio 2021 Community Edition
• Perl 5.26.1
• GNU make 4.2.1
• EPICS 7.0.4.1

2. Software Stack used to test with MSYS environment

• MSYS2 mingw-w64-x86_64-toolchain
• make 4.3-1
• perl 5.32.0-2
• mingw-w64-x86_64
• EPICS 7.0.4.2

Existing guide of EPICS installation on windows was verified for windows 8.1 and 10. When first prepared "Screen Outputs" were as per Windows 8.1. Screen outputs are showing software versions utilized. In next version of the document, I updated it as per windows 10, after which software stack for windows 8.1 got lost. Now even I don't remember what was it. I guess, I can get that information from github version history, but user should not have to look into github for that information.

As Now I am planning to test the procedure for windows 11 and EPICS 7.0.8, software stack for windows 10 will get lost, if I update the screen output.

So, I propose to add a list at the end of guide describing used software stack for verification for peoples reference. If you agree, I will update the guide accordingly.

This section seems to have a lot of old stuff and probably could be reduced

Include the relevant epics modules from https://gitlab.esss.lu.se/epics-modules/ into Epics related software

Hi,

I would propose that the following two modules be added to the list of supported software:

adsDriver:
sources: https://github.com/cosylab/adsDriver
documentation: https://epics.cosylab.com/documentation/adsDriver/

autoparamDriver:
sources: https://github.com/cosylab/autoparamDriver
documentation: https://epics.cosylab.com/documentation/autoparamDriver/

Hello,
There is a maintained version of EPICS CA for Node.js called node-epics-ca which is already included in the following EPICS web site,
https://epics.anl.gov/extensions/index.php

The GitHub and npm links for node-epics-ca are as follows,
https://github.com/wanglin86769/node-epics-ca
https://www.npmjs.com/package/node-epics-ca

In the CA_PROTO_VERSION command description, in Table 3, it says that the message does not contain the minor protocol version number for protocol version < CA_V411.

However, looking at the epics base code, I see the minor number being added to the message in older protocol versions.

For example, epics base version R3.14.0-beta1 uses protocol minor version 9 and adds the minor protocol version in the header of the CA_PROTO_VERSION message.

That seems to be the first version that implements the CA_PROTO_VERSION message. The previous version of base R3.14.0-alpha2 implements the CA_PROTO_NOOP message instead. That message indeed does not includes the minor version number, but 0 instead, in the header of the CA_PROTO_NOOP message. This version uses protocol minor version 8.

So, it seems to me that the minor protocol version number is available in the header of the CA_PROTO_VERSION message starting at protocol version CA_V49 instead of CA_V411.