Muon "RF": Copy Components from one instrument to another - Design

[KathrynBaker]

As someone using the same device/set of blocks in IBEX on multiple instruments, I want to be able to easily copy that component from one instrument to another.

Acceptance Criteria

• There are tickets to ensure that the workflow listed below can be achieved in a sensible manner by appropriate levels of developers, with consideration that this is a basic workflow only
• Ticket Muon "RF": Specific equipment control for items in the RF ranges tasks #7370 is updated as appropriate

User Workflow

• Device and/or blocks are set up in a component on Instrument A
• Device is moved to Instrument B, who want to use it in exactly the same way as Instrument A
• Scientist on Instrument B opens the configuration menu and selects import component from another instrument
• Instrument list is displayed, Scientist on Instrument B selects Instrument A
• A list of components on Instrument A is displayed, Scientist on Instrument B selects appropriate component
• Component dialog on Instrument B is displayed populated with the information from Instrument A (name etc.)
• Necessary changes are made to the setup by Scientist on Instrument B, and the component saved
• On looking at the list of components available on Instrument B the one just copied should be in the list (e.g. in Load Component, Edit Component, Add component in edit configuration, etc.)

Notes

• This is a ticket to design and make sure we have all the areas covered, however, if in discussion of this ticket it is realised that this is straightforward then the acceptance criteria can be altered to enacting the workflow
• Changes are likely needed in the GUI and the Blockserver
• Need to consider:
  • What to do if the other instrument isn't running?
  • How should the changing of non-default values for IOCs be handled?
  • Other items such as PV Sets etc.

[KathrynBaker]

Agreed to be useful across the whole facility

[Tom-Willemsen]

Impeded awaiting meeting with a couple or three developers to agree plan

Cases to discuss in the meeting:

• What happens to local blocks?
• What happens to non-local blocks?
• What happens to PV sets (note: PV set addresses are currently absolute)?
• What happens if the instrument being copied from is down? Do we care about this case?
• What happens if the instrument being copied from has a different IBEX version and therefore the config is incompatible (e.g. contains an IOC not present on the current instrument)? Do we care about this case?
• Do we do anything (warnings?) about IOCs which get most of their settings from autosave rather than macros? Likewise for IOC's with "special" files in the settings directories?
• How do we remind the user in the most user-friendly way that they will need to update IP addresses/COM ports etc for all devices in the copied component?
• Do we need special cases for protected and/or dynamic components?
• Do we need special cases for remote IOCs?

[rerpha]

What happens to non-local blocks?

i suggest we leave them as-is, as they may include things like the accelerator info or other things that are shared between instruments ie the position of muonfe motors. we should add this to the list of things to check on the user-friendly reminder to check com ports, IPs etc.

[Tom-Willemsen]

Meeting happening 5-Dec

[rerpha]

Cases discussed in the meeting( with DK, JH, TW and LJ ):

What happens to local blocks?

We should treat these relatively and prepend the instrument-to-be-copied to's prefix.

What happens to non-local blocks?

As the "local" box is ticked by default, it's unlikely that an instrument will have changed this by mistake to include their own prefix, so we should keep them non-local rather than use some witchcraft to try and change them. We should warn the user to double-check their non-local blocks (see later q.) as they may have a full instrument prefix in by mistake.

What happens to PV sets (values?) (note: PV set addresses are currently absolute)?

Note: A pv set/pv value is an automatic way of setting a PV's value on config change.
Complicated - these are all absolute (no local/non-local)
either:

• we know the inst prefixes copying to/from - change them if present
• put in big list of warnings but copy anyway
• easiest option - copy them anyway but fall over potentially
• not copy them PV sets/values are used frequently enough so we should copy them.
• add option to pv values for local/non local, then treat them like local/non local blocks

we should do the last option, but we need to make a ticket to make this work first and create an upgrade step to add this sort of thing - this also means there might be incompatibility issues if one or both instruments are not on the version. perhaps we should default to just seeing if there is a pv prefix in the PV set address when copying and then work out whether local or not.

What happens if the instrument being copied from is down? Do we care about this case?

we could use git to avoid this, but this is very untidy

the complexity of this case means we should just enforce that the server is up on both sides instead. note: make this obvious to the user ie grey out an inst in the list

What happens if the instrument being copied from has a different IBEX version and therefore the config is incompatible (e.g. contains an IOC not present on the current instrument)? Do we care about this case?

yes, we do care

we should enforce that if you want to copy someone's config they have to be on the same server version as you. because we deploy to groups it should be OK if we use these properly

hotfixes may be edge cases ie one instrument has 30 danfysik IOCs and the other doesn;t - we should be more careful about hotfixing rather than addressing this edge case. we should put in a check that all of the IOCs exist locally before copying a config then warn if not.

Do we do anything (warnings?) about IOCs which get most of their settings from autosave rather than macros? Likewise for IOC's with "special" files in the settings directories?

we could mark the IOCs that aren't copy-safe. this list would have to stay up to date. alternatively we warn the user saying settings in autosave will not be copied.
things in config areas wont be copied easily like motor controllers - should we blackexcludelist them? not just motor controllers either - eg danfysik

use soft black list - put it in a warning dialog saying they are potentially problematic. only disadvantage of this is its more work to keep update. you could load in a db via the standard isis db load but this is tricky to do.

globals.txt ?

same as the settings area - tell people to look in globals from copying-from instrument and see whats in there. we should add a way of editing globals (manager mode) in the GUI

really globals shouldnt be used and we should prefer people to use base components instead.

How do we remind the user in the most user-friendly way that they will need to update IP addresses/COM ports etc for all devices in the copied component?

in the same way that we warn them about other things. a dialog will do? with an unsure looking goat on it?

Do we need special cases for protected and/or dynamic components?

if you preserve the protected-ness of the protected components, you end up in a catch 22

we should preserve the managermodeness

we should ban people from copying components marked dynamic. it's not nice.

Do we need special cases for remote IOCs?

we can stick IOCs marked as remote in the warning dialog saying you may need to do extra setup.

Any other edge cases/details:
groups - just create them
autorestart/autstart - just preserve them
lvdcom iocs - same as the autosave things/special stuff in config areas - warn user
we should make another ticket if the "synoptics in components" ticket gets through before this

[KathrynBaker]

Putting into rework, second acceptance criteria not undertaken, and #7515 needs more detail for how this should be done, although the meeting has certainly addressed the cases Tom listed, I'm not sure how I go from this to making changes in our code base. Do I need a new server? Do I need to things to the blockserver? What does my UI look like?

I think I'd expect at least a ticket for the PV sets change, the changes for the remote component get in the UI and a simple save, the blockserver checks when saving locally would be an additional ticket, extra UIs for changing that which needs to be changed (don't just tell them to go change the IOC setup, prompt them with it before leaving the workflow, otherwise they might be trying to use COM ports that are assigned to something else for example).

[rerpha]

Issue should hopefully now be more descriptive and have linked 7515 from 7370

[KathrynBaker]

Thank you Jack, that is great.