Device modes

[Brow71189]

So this is a first attempt at the "burst mode" for the simulator cameras. This is stilla work-in-progress as we have to settle on how to implement it exactly.
There are also still some timing problems which is why the test for the new mode needs to use a much smaller pixel time for the camera than for the scan (https://github.com/Brow71189/nionswift-usim/blob/5cb5a6f6296b3fc1157c5c20d61d20ebc8e76086/nionswift_plugin/usim/test/Camera_test.py#L88, scan pixel time defined in line 108).
I think the reason for this is that we are not handling the flyback time correctly. Essentially the simulator always uses two flyback pixels but it doesn't actually add any extra time for them in free running mode. The correct behavior would be to not have flyback pixels in free running mode but instead just add a short wait time when advancing to the next line (although I don't know how to implement that correctly, since these times are on the order of a couple of 100 us). Maybe we can just have longer ones in the simulator which probably doens't hurt but makes this synchronized burst mode more reliable.

[Brow71189]

Now the timing in the camera and the scan is fixed so that the burst mode test passes without having to use different exposure times for scan and caemra. Hovewer, I needed to use a large flyback time to make it work because if the timing is too tight the camera still misses the sync signal from the scan.

[cmeyer]

Do we need some way of generally specifying a minimum flyback time?

[Brow71189]

No I think this is simulator-specific here. Normally you would only attempt this acquisition mode with a camera with good timing. And if you want some extra flyback time you can simply use the actual flyback time for that. Or what would be the difference between the regular flyback time and a minimum flyback time?

[cmeyer]

Overall, this patch would complicate the simulator cameras. We should consider the idea, too, of a separate simplified simulator camera or test-specific simulator instead.

[Brow71189]

Overall, this patch would complicate the simulator cameras. We should consider the idea, too, of a separate simplified simulator camera or test-specific simulator instead.

I agree that this complicates the simulator cameras, but since we want to support "burst" mode for our "real" cameras it might make sense to have it working with the simulator, too. But until we decide if and how we want to use the ModeController class we could of course put the new classes into a test module. The changes to the existing camera and scan simulator classes are not too big and they improve timing accuracy of the simulated devices, so it might be worthwile keeping them.