Our current panda setup is meant to do the following:
At the start of a row, wait for a GPIO signal from the motion controller
After encoder counts go above a position, enable a PULSE block which sends perioidic triggers (period = deadtime+exposure time)
After encoder counts goes above another postiion, disable this PULSE block so no more triggers are sent
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
Our current panda setup is meant to do the following:
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:
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