WIP: Add trigger to planar mode #150
Conversation
| self.camera_pulses = RollingBuffer(buffer_len) | ||
| set_impulses( | ||
| self.camera_pulses.buffer, | ||
| 1, |
There was a problem hiding this comment.
I'm abusing the set_impulses function here to get a camera pulses buffer for planar mode by setting the number of planes to one. I think we can get rid of this function and instead simply set the first item in the buffer to 5. Increasing the frame rate will be reflected in n_samples_period() becoming shorter, so no further modification of the camera pulses buffer is necessary.
| n_samples_trigger = int( | ||
| round(self.sample_rate / self.parameters.triggering.frequency) | ||
| ) | ||
| return max(n_samples_trigger, super().n_samples_period()) |
There was a problem hiding this comment.
Admittedly, I don't fully understand what is happening here. In the triggerless planar mode this used to be encapsulated by the least common multiple. I changed it to max() like in the VolumetricScanLoop as it made sense to me that it would be the size of the frame trigger plus the time until the next one.
|
I found two problems while testing that should be fixed before merging:
|
Adds a trigger to planar mode such that the frame rate can be set explicitly. This is what you would expect given the GUI but not what was actually happening behind the scenes. This solves the third point in #144.
In principle this does away with the non-triggered planar mode, but as I understood it has not been useful so far because there was no reliable way of getting the timing of the frames (see #2).
Since the basic functionality is working (feedback would be great!), I'm creating a PR, but the new class has to be reworked. Currently it is a merge between the old
PlanarScanLoopand theVolumetricScanLoopwithout regard to what is the most maintainable/elegant way of writing. The main reason for this is that I do not fully understand the working of some parts of the code.