swc-advanced-microscopy / bakingtray Goto Github PK

see view.connectScanImageListeners also see the end of the TODO at the end of the view constructor.

This happened only once (Aptil 2017): The acquisition was sitting around waiting for a trigger and doing nothing. I soft-triggered it via RDP and it started again. No idea why. Never seen this before. It happened on AMo_17 section 30. The result was a lost a tile as a result and the section is out of sync. Not good but has only ever happened this one time. Can't do much about it right now.

I think I had an issue with this last time. Double-check it works as expected via the config file.

It was incorrectly missing for ages and I was none the worse for it. I think it should go again. The info can be presented in the GUI text box.

e.g. I resume adk_singRabies_01 and am on section 112 of 160 at 9am on the 12th. The main GUI claims the acquisition will take 30 days and 17 hours to complete. In the acquisition view the finish time is listed as 02:02 on the 12th (day of resumption; so 7 hours ago).

This seems to happen only if listeners are connected to ScanImage but I'm not sure which are the problematic ones. I've tried a fresh start of MATLAB and left ScanImage doing ~2000 grabs with PMT auto-on and nothing happened.

So this setting is dangerous. There are work-arounds, such as turning off the PMTs with an API command at the conclusion of bake.

This is a problem if the user attempts to change the front/left position based on these coord values. Se we should cache them.

Choosing a different depth with the depth selector does nothing until new tiles are laid down. It would be nicer if it updated right away.

Often the same tile is laid down two more more times on adjacent x/y positions. This hasn't been seen with resonant scanning ever. The actual data are not affected. Only the preview image looks wrong. This appears to be a bug in ScanImage that is causing the data not to update, but this isn't clear.

At the moment the preferred solution to this is to upgrade the rig (even if it's linear scanners) to an FPGA.

First need to fix Issues #35, #27, and #36. Also see #44, which is an more simple way of achieving much the same thing.

These buttons do nothing during cutting so should be disabled. Currently they remain active and just do nothing when pressed during cutting.

Really don't need every motion command echoed to screen. When doing this, also check what else is at a message level of 3 and maybe bump it up if it's important.

The number depths, the step setting and so on should be set right away as the user loads the recipe and changes recipe settings. This is needed because the user should be able to hit Grab to check the depth adjust whenever they like. There should be no need for them to manually enter the Z-settings in the ScanImage window in order to test the illumination correction.

If so, make it optional. Otherwise enable it. Could also see what's taking the time and fix that.

I think this only happens at the start of an acquisition. Figure out some way of avoiding this. e.g. maybe even have a lock variable that will queue a command or block a command?

It's currently not automatically set. Neither is it logged to the ScanSettings to be re-applied by scanner.applyScanSettings when an acquisition is resumed.

Does Candle-J and how slow is it?

From a fresh start of MATLAB, the laser did not switch off at the end of acquisition. There is no possibility that the leaveLaserOn flag was set to true. I added more logging messages to indicate the state of the laser and when it will be turned off (8f16fcd) in order to track down what is happening.

Ours works well with a flyback time of 75 ms and a lag of 9 ms for the sorts of waveforms we typically produce.

Handle the scenario where the user is resuming an old acquisition and has not gone through the preparation phase.

Currently it's possible to stop and resume an acquisition by entering a section start number one larger than the current section. The system then re-starts. We could automate this process by writing a method that finds the section ID and tile position of the last acquired data point. It then knows where to pick up. A GUI confirmation box will appear. The user selects if they want to carry on. The calculated values are applied to the recipe and and the position array and we begin.
If this works, there will be no reason for section start num to even be a setting in the mosaic file. So we could look to see if it's used elsewhere (even used by Stitchit). Then remove it if needed. We will only need the BT.currentSection (or whatever it is) property.

Loading an existing recipe file discards the front/left and cutting position. These need to be re-loaded if resumption is to be possible. However, the user should also be able to save a recipe for generic use. So if we select save, the recipe should save only the generic stuff. The system however should be able to write the full recipe to allow resumption.

In the event of the z-motor traveling back down again, the z positions are saved to the log file.

Confirm that we get a sensible dialog warning of some sort if the user asks for more z-depths than are available. BakingTray should perhaps re-set the number of sections automatically? See BT.checkIfAcquisitionIsPossible

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.

At the moment the user needs to use the command line.

If missing we can default to the current directory.

If the channels to display are changed after the acquisition view is opened, the channels pull-down is not updated. Same with number of depths.

I stopped an experiment at ~section 33/120. Moved the front left pos. Changed the section start number to 34 and total sections to 80 then started again. The total number of sections in the acq view is wrong: 113.

Report to screen if the following were not set to the expected values:

• Bidirectional scanning
• Z intensity correction

Not sure which module should do this (e.g. we might be imaging with a camera, so BT shouldn't raise this warning directly).

Could also provide a check-list that we can optionally disable in the user settings.

See also Issue #59

This will be a helpful for tweaking the front/left position and for eventually drawing a box around the area to image.

Maybe this can be done in ScanImage via a user setting or alternatively with the system settings file or even a new settings.

Place large step above small step and label them.

This is the fastest way of having the system become easy to use for a beginner.

Should be an easy fix.

We need to be able to zoom in order to allow the user to draw a box around the sample. Currently this messes up the number of microns per pixel.

The Mai Tai automatically closes the shutter when switched off so the GUI is clearly failing to read the shutter state after the "Turn Off" button is pressed.

Set up acquisition with channels 2 and 3. Both are saved. I see only blank data if I select the channel 2 preview, however.

Don't know what led to this. I did a fresh start. Set everything up. Hit preview and the preview image was initially too small and the first row of tiles was of the screen. I closed and re-started the window and everything worked fine thereafter.

It should be possible for the acquisition view to handle any changes in the recipe without needing to be restarted. I think this is the case now, TBH, but I need to double-check. Then we can remove the disabling of the main view when the acquisition view is present.

Also

• Display projected disk usage to main view (049926e).
• Move the code from bake to BT.checkIfAcquisitionIsPossible so it blocks acquisition if it fails. (e8afa80)
• Update status text in main view when the number of channels to acquire is changed. (461b949)

This is a new bug. Although the stall may be due the MATLAB licence server being down. This is unusual.

See line 639 in chooseChanToDisplay. If a channel was selected as being displayed but not saved the find statement returns empty which cause the GUI channel select to fail to render.

This is similar to what I see with linear scanners (#20) but I don't think I've noticed duplicate tiles. I don't remember seeing this when I first started resonant scanning. By the time I noticed it, two major changes had happened:

1. I dropped the user functions and switched to listeners (around 5th July 2017 -
   b5a9c9a)
2. I began imaging with rectangular tiles (around 1st July)

The blank tiles appear in the preview window only and are not saved as such. No data are lost. However, they will be a problem, when we want to analyse incoming data for adaptive tile patterns. The first thing I'll do is write a test class to reproduce the problem for Vidrio. This will tell us if it's ScanImage itself that's serving empty data or if I'm somehow failing to copy the data to my buffer.

Press Focus and open Prepare GUI. The image on screen pauses at regular intervals. Likely a regular serial command is blocking. Could run this in a parfeval to stop this bahavior or place in a timer. Alternatively, it might be possible to listen to one of the properties (such as currentPosition in linearstage). The problem with the latter approach is that a motion command does not currently cause currentPosition to be updated automatically. The former approach required the parrallel compute toolbox to be present and might be dangerous. Before proceeding, should check which axes are causing the problem.

See the TODO on ~line 68 of BT.checkIfCuttingIsPossible

This happened on section 75 of CH120.

Never seen this before. Section 76 is fine. Should look through this sample and see if this pattern is seen elsewhere. I've seen this sort of effect happen when cracking open the door to the mesoscope. A little light creeping in is added as an offset to the real signal and it makes the signal look brighter.

However, what this really looks more like is that the deep depth is getting the power for the upper depth and the upper depth the power for the deep depth.

If this doesn't recurr, it's no big deal.

At the moment this is done by ScanImage because of the auto-PMT feature. This has shown itself to be prone to crashing (#13) at least when listeners are attached to the ScanImage object. We therefore should just leave the PMTs set to non-auto and turn them off at the conclusion of bake. So we need the facility to do that. Need to decide if this should be done via ScanImage or we make a separate detector component. Contacting Vidrio to see if they can talk to the ThorLabs PMTs.