Acquisition dead-time

[raacampbell]

I have noticed when working on stress-testing that the dead-time in triggering the next tile is not always long. Early on in developing stressTestTilePreviewBuffer there was very little time between stacks. At some point something happened (I don't know what) and there was some 0.5 seconds or so of time between frames. Maybe more. Then it went back down again and is fast. I'm not sure right now what I saw. If it slows again I need to work out why this happened.

[raacampbell]

SIBT is slow... making non-blocking stage motions is also slow. High dead-time. If I run an SIBT acq then close BakingTray and start the stress test, only the first tile is acquired. I have re-start ScanImage for it to work. Something is clearly not optimal here...

[raacampbell]

The SIBT destructor was not being run when BT was destroyed and so the listeners were hanging around. This is fixed: 3461750cb32d3dd8e175ec390fa693a6939f35c1 This explains a lot of odd past behavior. I still find I need to re-load the user settings to get the stress-tester working beyond acq 1, though. So there is some setting it needs to apply which it is not applying.

[raacampbell]

The slow behavior in SIBT is seemingly due to SIBT.channelsToAcquire being run repeatedly. However, I don't know what's calling it yet. It could be ScanImage but it could also be something in my code. I set this property to be AbortSet in ScanImage and still I see the callback spamming everything. I think a lot of my problems will be solved when this is fixed.

[raacampbell]

Got rid of that callback, which may make some things a bit smoother but isn't speeding up things. Tried stopping the stage motions, got rid of the acquisition GUI, still I can't pull in acquisitions at the speed of the stress tester. Hmmm....

[raacampbell]

Add a minimal tileAcq callback in SIBT (962d52138f8fb7cecdad455341cec0cdb47e5f19) and did some timing:

49 tiles, 2 depths, 512x512, 44.77 Hz
Regular SIBT callback: Elapsed time is 35.7 seconds.
Minimal SIBT callback: Elapsed time is 35.6 seconds.
The stress tester: about 9 seconds

What the heck is slowing it down this much?

[raacampbell]

Stripped down ever more. Still slow:

>> hBT.scanner.armScanner; hBT.scanner.initiateTileScan
Setting up z-scanning with "step" waveform
Hit SIBT.isAcquiring
Hit SIBT.isAcquiring
Armed scanner: 13-Jul-2017 22:02:36
Hit SIBT.isAcquiring
Hit SIBT.isAcquiring
Hit obj.tileScanAbortedInScanImage
Hit SIBT.isAcquiring
Hit SIBT.isAcquiring
Waiting to disarmHit SIBT.isAcquiring
Turning on fly-back blanking
Disarmed scanner: 13-Jul-2017 22:03:05

[raacampbell]

Ok, good: f61616019c0f8e6282bc7c75d1b73423fda701d1 The pause statement in the callback (which for some reason I thought was necessary) was adding way more time than expected. Without it we chug through the frames in 5 seconds. Obvious really :1st_place_medal:

[raacampbell]

It was creating the tile positions each time, that slowed it down. I've stopped it doing that. Now it runs at:

• 11.5 seconds with no motions at all and no image logging.
• 10.5 seconds if I also disable the saving of the tile positions. Maybe saving those as text or every few files will speed this up?
• If save the positions and move the stages but don't do the blocking then I get 14.5 seconds.
• If I add blocking I get 22.5 seconds. In the loop that looks like for the stages settling I changed the pause from 0.05 seconds to 0.01 seconds and the acquisition time dropped to 20.4 seconds. So possibly big way of speeding stuff up would be to send a hardware trigger from the stages to acquire the next plane
• I then enable the option to import the last frames and time goes up to 21.2 seconds from 20.4. That's OK.

This is the faster version with the the tile positions not calculated after each position: c1e82b9f00a48147c1ef9e76572df93240d462e7

[raacampbell]

All this seems to make sense. Maybe the tilePosition method in recipe became slower recently and that's why I noticed the speed issue more? With square tiles I now see nothing missing in the preview (scanning an displaying all channels. Also fine with rectangular tiles now. Must have been the excessive pauses from the tilePosition. Final job will be:

• [x] to put back all the listeners and confirm that I still get nice stuff happening
• [x] Check that the AbortSet in Channels.m isn't needed
• [x] Check how fast I can go before I see lack of settling in the tiles
• [x] The stress test gives me 3 seconds with one channel displayed but 5 seconds with all four. So should display just one.

[raacampbell]

If the z-flyback is non-zero and the trigger signal comes in too soon then the cycle locks up.

[raacampbell]

Getting the stage positions moves our test time (49 tiles, no PIFOC delay) up from ~4.5 seconds to more like 8 or 9 seconds. So we make it optional: 59bea5bd83410e5eac0a96864b1bcc62a7a5f2ac

[raacampbell]

Simply having the acquisition GUI open (with no tile import and no image update of the (now) blank tiles) increases the test acq time from about 5 or 6 seconds to 15 seconds! Wow. Clearly we have listeners that are doing bad stuff. Next job is to track those down. The culprit is:

function updateStatusText(obj,~,~)
            if obj.verbose, fprintf('In acquisition_view.updateStatusText callback\n'), end
            endTime=obj.model.estimateTimeRemaining; % LONG TIME HERE

I made changes to this method: 346dbd6af6d3909350d96118c5f04d117622d198 Now there is no time penalty to having the GUI open and the image not updating.

[raacampbell]

The deadtime is influenced a good deal by the PIFOC flyback (Issue #24). If this is longer than 50 ms we start to see too much a decrease in speed.

[raacampbell]

By now (73151384552751a781029f8dbafa7a9f395bb724) I think we're mostly done. Last thing to change is to prompt the user to have just one channel displayed for speed. But we'll leave it up to them. This can be documented so they know they deal. Maybe there will be a reason why thy want multiple channels open. There is relatively little overhead in having several channels open if only one frame is displayed in ScanImage. This is not much slower than have one channel and and displaying all depths.