PandA grid scans: Safeguard against varying smargon speed

[olliesilvester]

Our current panda setup is meant to do the following:

1. At the start of a row, wait for a GPIO signal from the motion controller
2. After encoder counts go above a position, enable a PULSE block which sends perioidic triggers (period = deadtime+exposure time)
3. After encoder counts goes above another postiion, disable this PULSE block so no more triggers are sent
4. Other stuff not relevant to this issue

This assumes that the PandA is going at exactly the right speed by the time we get to bullet point 2. If we are going too quickly or too slowly, the number of triggers received may be off by a tiny amount. The last time we tested the panda, we saw an occasional missing trigger. We concluded that this was either down to what has just been described, or due to lost encoder counts due to accelerating the smargon too quickly.

We should instead do the following:

• When Hyperion sets up the PandA, calculate how many triggers are expected and send it over to the panda
• The PandA should wait for the GPIO signal, then wait for encoder counts to go above an initial value, and then periodically send out triggers until the expected number of triggers have been sent. This can all be done on the sequencer table, we don't need to use the CLOCK or PULSE blocks
• Other stuff not relevant to this issue

This will rule out missing triggers from the smargon going at the slight wrong speed. If the speed is wrong, we will still get the triggers, but they will be in a weird place (and this will be obvious from data collection). When PVT scans are working, it will setup the panda in a similar way, but it will be nice to do it here first so we can compare the times of panda scans using the motion controller and using the ophyd-async flyscan

Acceptance Criteria

Do the above, and update documentation https://github.com/DiamondLightSource/hyperion/wiki/PandA-constant%E2%80%90motion-scanning

[dperl-dls]

• need position capture to get statistics about the solution here (separate ticket)

@olliesilvester says this is medium (the rest of us think large)

@olliesilvester and @DominicOram are banned from doing this ticket so other people can get some panda experience

[olliesilvester]

See #1485 for the PCAP part

[DominicOram]

Waiting on testing time on the beamline - better to do with beam