Add more structure to UI

[GDYendell]

FastCS now supports creating sub screens for sub controllers. This should be implemented for Eiger to add some more structure and organisation to the UI, e.g. thresholds can appear on a subscreen.

Acceptance Criteria

• Thresholds and other suitable sub groups split into sub controllers and appear on separate screens

[jsouter]

Hoping to get more testing time with a real Eiger on tuesday so I can make a note of the JSON responses to putting to various fields - especially those with non-unique suffixes like "mode" so I can update the tickit sim. Since SIMPLON API returns a list of changed parameters, I need to check if it attempts to make these unique - currently fastcs-eiger doesn't handle these parameters properly in update() - they silently fail in the getattr. If they're not unique we may have to try and use context to determine which of the parameters it changed by considering which parameter we put to.

[GDYendell]

I have been making updates to the tickit sim while working on fastcs-eiger. There are two pending PRs:

• https://github.com/DiamondLightSource/tickit-devices/pull/111

• https://github.com/DiamondLightSource/tickit-devices/pull/112

  What version of the tickit sim have you be trying?

[jsouter]

I have been making updates to the tickit sim while working on fastcs-eiger. There are two pending PRs:

• Update Eiger API tickit-devices#111
• Add Eiger stream2 support tickit-devices#112

What version of the tickit sim have you be trying?

The eiger-stream2 branch

[GDYendell]

The eiger-stream2 branch

OK that's good. I think that is getting pretty close to the real API but there are some missing things for sure.

Since SIMPLON API returns a list of changed parameters, I need to check if it attempts to make these unique

Yes I had noticed this and we can handle it because the changed parameters are always in the same subsystem, so we just need to check the subsystem of the put parameter. This would also be be made easier by splitting subsystems into their own sub controller, because then the attribute will always match the leaf of the URI, whereas currently we combine the last two so it is not as clear.

[jsouter]

Yes I had noticed this and we can handle it because the changed parameters are always in the same subsystem, so we just need to check the subsystem of the put parameter. This would also be be made easier by splitting subsystems into their own sub controller, because then the attribute will always match the leaf of the URI, whereas currently we combine the last two so it is not as clear.

Okay great, I'll have a go at that then. I did some testing today so I have a record of what the list of responses are for each parameter (I wasn't sure if this list changes depending on the choice of value we put but I assume not since some parameters like photon_energy return a list of ~10 parameters when setting the param to its current value), can maybe update the sim too based on these.

[jsouter]

Draft here: https://github.com/DiamondLightSource/fastcs-eiger/pull/51

Relies on changes to the tickit-devices sim, addressing this https://github.com/DiamondLightSource/tickit-devices/issues/114