Triggered ASI Z-Stack Acquisition

[AdvancedImagingUTSW]

Currently, with the new mesoSPIM that we built, it takes ~30 milliseconds to move between adjacent image frames in Z and F.

*** ZStack move stage time: 1.025151014328003
*** ZStack move stage time: 0.0317995548248291
*** ZStack move stage time: 0.03197789192199707
*** ZStack move stage time: 0.03197622299194336
*** ZStack move stage time: 0.032907724380493164
*** ZStack move stage time: 0.03191113471984863
*** ZStack move stage time: 0.03191351890563965
*** ZStack move stage time: 0.031972646713256836
*** ZStack move stage time: 0.032910823822021484
*** ZStack move stage time: 0.03197526931762695
*** ZStack move stage time: 0.03197216987609863
*** ZStack move stage time: 0.03191494941711426
*** ZStack move stage time: 0.03297066688537598
*** ZStack move stage time: 0.03196883201599121
*** ZStack move stage time: 0.03197002410888672
*** ZStack move stage time: 0.03197503089904785
*** ZStack move stage time: 0.032911062240600586

Some of this is standard stage overhead, but presumably the largest portion is serial communication with the device. However, the stage can be set to move a certain distance upon receiving a TTL trigger too. This is how the mesoSPIM software does it... This does seem worth evaluating...

The trick will be to see how to differentiate between tiling stage movements, which will be done with the serial communication, and scanning stage movements with TTLs.

[AdvancedImagingUTSW]

More information here

[AdvancedImagingUTSW]

Quick thoughts...

Would probably need to specify if the ASI stage will have triggered axes in the configuration file. If an axis is listed as triggered, we would need to pass the ASIStage class a nidaq connection. The microscope object would need to evaluate this, and handle it appropriately.

The default for the ASIStage should be None, and any methods within it would have to accommodate this... For example:

ASIStage(microscope_name, device_connection, configuration, device_id=0, nidaq=None)

The next tricky part is to be able to call serial commands for certain movements, and have the DAQ trigger the stage movement for others. For the latter case, we would know that the stage has completed its move when it returns a TTL. That alone requires having the logic for a digital input device, which requires repetitive start/stop commands after each command (pretty sure). And all of this has to be done in a way that is sufficiently abstract that it doesn't interfere with other stages.

It's not a small task.

[zacsimile]

Allen Inst. seems to have solved this for Tiger Controllers at https://github.com/AllenNeuralDynamics/TigerASI/blob/main/src/tigerasi/tiger_controller.py, including details like caching positions in move_relative serial moves for subsequent TTL moves. May be able to copy + paste the TTL logic from there.