Closed gilesknap closed 10 months ago
@coretl please comment if the above looks wrong.
@coretl please could you write down what you said in the verbal response to this issue? I tried but became fuzzy on the details.
I'd like to make the point that we should support people who don't want to use ibek and maybe even bobs. Therefore the opi section should include a list of file globs for copying into the /epics/exports/opi area. This leaves indexing up to the developer - but it provides the ability to file inside the container the correct versions of the GUI files for the support modules that you have built into your IOC executable.
ibek support generate-links
should take globs of paths to make links for in /epics/opi
. These paths should always link pvi yamls, but can also link bobs and pngs for pre-generated screens. Not sure if it should be doing ibek yamls too, as they need to go in a different directory. Maybe rename to link-opi
and add a link-ibek
command that puts them in /epics/ibek
? Or pass to the register
command as an arg?/epics/exports/opi
or /epics/opi
? What else do we want to export?prefix
and file path. This needs to be run either manually in start.sh
with a provided formatter argument, or from the ibek start.sh
with formatter from the ibek ioc.index.bob
from the opi
entries of all entitiesI think if we do this we make bob files available even if you don't use ibek ioc yaml files
Today's meeting discussion decided:-
ibek runtime generte
from the shellibek support generate-links
will copy ibek support yaml files as it currently does at container build timeibek runtime generate
will:
@coretl @GDYendell did I forget anything?
I think that looks right, although ibek support generate-links
should link not copy ibek support, and maybe it should be called ibek support link-ibek-support-yaml
?
I think this looks right.
generate a db template for ophyd and add it to the subst (for ophyd info tags to be added to PVs)
Does this mean it will be appending to a substitution file that is initially created at generic-ioc build time?
I think ibek support generate-links
is fine.
I think that looks right, although
ibek support generate-links
should link not copy ibek support, and maybe it should be calledibek support link-ibek-support-yaml
?
It truth it could be called ibek ioc link-ibek-support-yaml
and get run once in the main Dockerfile - at present it looks for all support modules and copies all it finds.
I think this looks right.
generate a db template for ophyd and add it to the subst (for ophyd info tags to be added to PVs)
Does this mean it will be appending to a substitution file that is initially created at generic-ioc build time?
I think
ibek support generate-links
is fine.
The main subst file is created when we read the IOC instance yaml at runtime. I think we could just have the ophyd one generated at build time as as separate subst and expand >1 subst at runtime, include >1 db file. Or we could merge subst. Or we could save info for generating the ophyd parts of the one global subst (in a yaml file of course!)
I think that looks right, although
ibek support generate-links
should link not copy ibek support, and maybe it should be calledibek support link-ibek-support-yaml
?It truth it could be called
ibek ioc link-ibek-support-yaml
and get run once in the main Dockerfile - at present it looks for all support modules and copies all it finds.
It needs to be run once per support module so we can decide based on version number which support yaml to link, each time we add a new database template to expose to ibek we will have to change the support yaml so will have a number of versions
The main subst file is created when we read the IOC instance yaml at runtime. I think we could just have the ophyd one generated at build time as as separate subst and expand >1 subst at runtime, include >1 db file. Or we could merge subst. Or we could save info for generating the ophyd parts of the one global subst (in a yaml file of course!)
I think that whenever we get a xxx.pvi.device.yaml
we should generate a xxx.pvi.bob
and a xxx.pvi.template
. This should be able to be generated whether or not we are using an ibek.ioc.yaml. Because of this it should always use that well know filename pattern, and use $(prefix)
as the pv prefix.
If we use an ibek.ioc.yaml file for each instance we should insert instances of all dbs and xxx.pvi.template
in the substitution file. If someone manually makes a subst file it is up to them to make the xxx.pvi.template
files.
@GDYendell think we are ready to close this?
In order to progress #110.
On 6 Oct we came up with the following:
ibek support generate-links
command to copy bobs and pvi files into the/epic/links
folder. This probably requires extra arguments to specify which hand-crafted bobs should be copied. See Hereibek runtime generate
to make bob files from PVI files at IOC instance launch time. See Here This function will also generate the required index.bob for the IOC - this needs to be a button for each screen instance with the PREFIX macro set accordingly.Note that we were undecided about whether generated screens should have a PREFIX macro or should use $(P):$(R) or whatever the unique identifier is for the given support module.
Some work already started in
pvi-changes
branches ofibek
andioc-adaravis
Gary will do this work to get an intro to ibek.