auto-generation in the future
Opened this issue · 4 comments
Having used PVI to make some screens for Aravis IOCs I'm wondering if we intend to support auto-generation as the primary way of making pvi files or if we intend to treat them as manually editable entities going forward.
With builder to ibek it is clear that this is a one off as builder will be retiring and hand edits of support yaml will be the only option in future. But with PVI the source of autogeneration may continue could continue.
If we intend to keep the conversion and maintain PVI device files via re-running the conversion then there are a number of changes that would need to be made to make this viable.
@coretl @GDYendell I've scheduled a meeting to discuss this Next Friday and will use these notes as the basis for that.
In my view auto-generation should be maintained and updated so that manual intervention is not required. The source of the auto-generated device files (.adl's and .h's) are unlikely to go away and the area detector modules continue to be updated with regular releases. Therefore not doing auto-gen leaves us with a maintenance headache. The same is true of most other support modules.
It would be nicest if each ibek-support folder contained a single file that described how to auto-generate pvi device files from the support modules that exist inside the generic IOC. I started a bash script to do this here but it is woefully inadequate, and I would prefer a yaml file with an associated command in pvi that consumes it.
If we have this we can generate device.yaml at support module build time instead of checking in hand coded ones. We could still allow override by checking in for where the manual edits can't be automated.
The features of this file would be:-
- list of templates and header files to generate devices from
- ability to patch the device file yaml in the following ways:
- fix problems with camelCasing vs SnakeCasing of names and labels (or maybe this is a bug that can be fixed?)
- Find a signal by name and modify / add / delete any field in it
- e.g. adding format: 4 to longStrings widgets (I assume that from the db template there is no way to tell that something is a longString so this must be explicitly added)
- re order groups in some fashion so that the most useful group is not scrolled off to the right - this reordering needs to be across base classes - e.g. NDHdfFile plugin defaults to having NDFileBase at the far right and its the most important group.
- remove a group entirely.
- it seems that everyone derives from NDFileBase but only the file writers use it's db template - we need to drop that group when not needed.
In addition we need some new features / bug fixes to make prettier screens.
This needs to make the label / demand / readback on separate lines because it needs MUCH more width. widget:lines:2 just makes two narrow two line widgets.
In these two examples widget type checkbox seems to do the wrong thing, should I use a different type or is this a bug.
In truth this first set of auto generated screens came out pretty good. There is not a massive list of things that need to change.
One more thing. AD screens are not showing the status group containing PVS like BL20J-DI-PHDGN-03:CAM:ArrayRate_RBV
A problem with repeating the conversion is we are stuck with the grouping extracted from the adl files. Or would have to edit the adl files to change what appeared in the generated bob files.
widget:lines:2 just makes two narrow two line widgets
I am not sure what this means, but I am not surprised Text{Read,Write}.lines does not do what is expected because I don't think I implemented anything for it
In these two examples widget type checkbox seems to do the wrong thing, should I use a different type or is this a bug.
I think this is a bug in PVI