Motor settings: restructure?

[Tom-Willemsen]

Where?

Currently motor settings (e.g. jaws.cmd) are sometimes found in a few different places:

• c:\instrument\apps\EPICS/support/motorExtensions/master/settings
• c:\instrument\settings\...\galil
  • Or ..\jaws, ..\motorExtensions and other similar directories
• Sometimes in c:\instrument\apps\epics\support\ioctestframework\master\test_support or test_data and similar directories (for IOC tests)

This can cause problems when settings get out of sync with each other, which recently caused an issue on GEM. See discussion in teams "support-issues" channel 23/04/2024 @ 14:30 for further context.

Probably a brief meeting to decide a plan and then spin off any required tickets

Acceptance criteria

• Agreed plan about (through either a meeting or online discussion):
  • Exactly which areas are the "authoritative" copies
  • Where the settings are kept so that they can be accessed by both instruments and IOC tests
  • Minimising duplication so that settings in github and in the instrument settings area don't diverge.
  • Whether there are different/better structures for any of these areas that we want to adopt
• If trivial to implement, implement the plan. If not, spin out tickets

How to Test

verbose instructions for reviewer to test changes
(Add before making a PR)

Time in planning meeting (18/07/24)

1:44:00

[rerpha]

can we remove c:\instrument\apps\EPICS\support\motorExtensions\master\settings in favour of just making a branch to be merged into whatever instrument they apply to? if they're not used by tests they are probably superfluous?

[Tom-Willemsen]

meeting tbd

[Tom-Willemsen]

Meeting 14th August @ 15:00

[Tom-Willemsen]

Outcome of meeting

• The central source of truth will be c:\instrument\apps\epics\support\motorExtensions\master\settings\INST_NAME
• At least initially, the structure below that directory will be equivalent to the existing structure under the settings area
• Long term view:
  • The settings area should be "numbers" (e.g. motion setpoints files describing mapping of pos name <-> motor SP)
  • The motorExtensions area should be "code" e.g. st.cmd fragments etc.

Acceptance criteria for implementation phase of this issue

• Existing motor settings in c:\instrument\settings\... for each instrument are copied to c:\instrument\apps\epics\support\motorExtensions\master\settings\INST_NAME
  • Check and adjust any paths as necessary, but do not do any structural refactoring
• Write an upgrade script for the next deployment that:
  • Runs git log on the motor settings directories
  • If any commits exist in between the date that the settings were copied and the deployment date, raise a message stating that a manual re-copy/re-merge needs to be done
  • If no commits exist in between the date that the settings were copied and the deployment date, delete the motor settings directories in c:\instrument\settings\....
• Adjust the motor st-common.cmds for all motor controllers to look at motorExtensions\master\settings\INST_NAME rather than the settings area.

[Tom-Willemsen]

PRs:

• Ticket8427: migrate all motor settings from instrument config directories EPICS-motorExtensions#65 (the big one)
• Ticket8427 EPICS-upgrade#82
• Point st.cmds at new settings area EPICS-ioc#875
• Ticket8427 #8497

Follow-up issue for refactoring:

• Motor settings: clean-up/refactor #8498

To review:

• Check motor settings have been migrated from config area -> motorExtensions
  • Check any hard-coded paths have been adjusted as necessary - but note that structural refactoring was defined as out-of-scope for this issue, so the adjustments should just be things which were "wrong", e.g.:
    • Broken paths
    • Clearly broken code e.g. stuff that had leftover git conflict markers
    • Obvious mistakes in the config area (e.g. instruments defining settings which don't make any sense for that instrument, where the settings have clearly been copied-and-pasted from elsewhere)
  • This is the bit of the change that would be good to pair-review, there are a lot of settings migrated over, I have done my best to go through and check these for any hard-coded paths and any obvious mistakes, but would be good to have several pairs of eyes on this to reduce the chances that I've missed things.
• Check that the motor IOCs for galil, galilmul, mclennan, linmot, smc100, sm300 and twincat have all been adjusted to point at the new settings area correctly
• Run a representative selection of ioc system tests using motors and motor settings to prove no obvious functionality has been broken
  • e.g. python run_tests.py -t galil galilmul mclennan linmot refl jaws sm300, and any others which are seen as useful.
• Check the upgrade script works to remove motor settings from the old place on next deploy, and gives a sensible enough error for a developer to follow if it can't be done automatically.