[DSSC] Allow 900 memory cells for DSSC darks to workaround appearance of cell 810

Description

Hotfix already deployed by @esobolev to workaround the sudden appearance of cell 810 in the DSSC data stream. This check should disappear entirely in the long run.

How Has This Been Tested?

Used in production

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Reviewers

@ahmedk @danilevc

changed milestone to %3.11.4

LGTM

merged

mentioned in commit 32e2a3e4

Thank you for doing the fix, it's much appreciated for this beamtime!

However, there's two issues on the long run:

1. This cellId count rounding to the nearest value is kinda silly (we all know it, but since we inherited this notebook, eh, and I'm the one to fix this)
2. if there's more than 800 cells, the detector is in an undefined state, and this should fail and the detector should be fixed (by power-cycling).

So, LGTM, I'll rework this along with the rest of the notebook.
I'll do a follow-up MR until then to show a message in the report, as I also want to have this as part of the detector sanity checks.

For more context, here's a summary:

Incorrect veto configuration was applied ("Veto these: range(11, 2000, 2)"), whereas the expression must fit the following check: abs((exp.stop - exp.start) // exp.step) <= 800.


Veto pattern that extend beyond the number of available memory cells (800) are known to cause the PPTs to send invalid cell Ids (eg. cellId 810).
We know that the fix is to power cycle the detector completely (auto-on).

This happened late one evening, and it was decided with users (H. Chapman) to not power cycle the detector as the online data analysis was satisfactory.
This was not communicated beyond DET, SQS, and users.

We implemented a macro to validate supported veto pattern within Karabo, and will integrate it to the DsscControl: https://git.xfel.eu/karaboDevices/dsscDevices/-/issues/29

mentioned in merge request !927 (merged)