DiamondLightSource / DiamondLightSource/pmac

Improve pmac DB templates for tidier PVI engineering screen generation

Open
#141 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
31
Forks
25
PR merge metrics
No merged PRs in 30d

Description

## Intro
During a discussion on #140 with @coretl and @shihab-dls we decided on the following to improve PVI auto screen generation for pmac.

## Simplified Templates

- Create a new pmacAxis.template that incorporates:
- all things included by dls_pmac_asyn_motor.template (cs and non-cs flavours)
- PLUS axisStatus.template
- i.e. ALL the per-axis things
- And a new pmacController.template (name to be decided) that includes
- All the templates we currently instantiate per Controller
- EXCEPT axisStatus * n
- i.e. ALL the per-Controller things (one of each)
- Now we can make PVI devices for each of the above and have:
- N Axis screens, 1 for each axis including all of the names:
- `$(P):AXIS$(ADDR)` for axis status stuff
- `$(P):$(M):` for motor record and supporting records
- `$(P):M$(ADDR)` as an alias to the above

## Alternative

Writing this up it occurs to me that we could instead:-
- remove references to pmacAxis.template when rendering controller templates
- insert an include of pmacAxis.template into dls_pmac_asyn_motor.template (and CS equivalent)

This would be backwards compatible because the set of PVs created would be the same (except that non-existent axes would not get axisStatus - same as the above)
@coretl do you prefer this?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.