Generic way to deal with devices that have different behaviour when there is no beam

[DominicOram]

There are a number of devices that might have different behavior when there is no beam e.g:

• Undulator gap is disabled
• XBPM feedback will not lock

At the moment for testing when there is no beam we:

• Set TEST_MODE=True on the undulator
• Set the feedback threshold to 3000 in the IOC

This is a bit messy and poorly defined/documented. It is also liable to cause issues if we forget to reset things when beam comes back. We should come up with a standard way of doing this.

Acceptance Criteria

• We can set a parameter somewhere to say "we know there is no beam"
• Devices loaded in dodal will then have different behaviour in this case. Note this shouldn't just be mocked behaviour as we are beamline testing we probably want other behaviour of the device
• There is some protection to make sure this setting is not on while there is beam
• If we cannot think of a nice automatic way of doing this at least document the standard for it

[stan-dot]

Semi-structured thoughts on this.
Modeling the system:
change in beam state -> [black box] - > change in device behaviour
Requirements:
In the most generic way the devices would adapt to beam going off randomly and going back again.
Manual setup would be a second-best option.
devices in a dodal.beamlines.x module have access to params defined there, and also imported ones.

Whether the beam is on or off is an instance of a Synchrotron State and since we already have a synchrotron device it could contain this. It could expose an endpoint later queried by blueapi and blueapi could refresh_environment, this time passing arguments to the devices to adapt to this new state.

Alternatively synchrotron state could be polled from some other microservice, for instance an argus-running blueapi server with just synchrotron device loaded (or expanded synchrotron device with expanded diagnostics?). Or just no python just a REST point summarizing EPICS state?

[DominicOram]

In the most generic way the devices would adapt to beam going off randomly and going back again
It's important to differentiate between:

1. I am testing and I know that the beam is off, this is fine
2. The beam has just gone off "randomly"
   This issue is just for use case 1. In this case we want to be able to, manually, put all the devices in a state where they don't worry about the beam being off and let us do whatever testing we want. In the case of 2. we likely want to error loudly to the user as it means that the won't have any data.

I think for this reason we don't necessarily want to be using the state that is given to us by the Synchrotron device but rather be able to set the flag manually. Scientists have also expressed some concern about how much they can trust the state from the Synchrotron device to be correct and have anecdotally seen times the state says we're in shutdown but actually we're in run. The main concern with this issue is that we never have this testing flag set to on when a user is at the beamline. One way to do this would be when you set the flag you must provide a length of time that you want it to be high (e.g. how much time you know you are spending testing) when the time is up devices will be reset back into a production state where they expect beam.

[Relm-Arrowny]

I think for case 2 you can just check the front end permit and/or the beam current, if the front end is open scream at user we are still in testing mode.
You can probably use it as a state for stan idea too. No one is taking beam if there is no beam current or if the front end/permit is close. But you probably want an override just in case you ever want to test the frontend stuff when there is no beam.