Property cache applied after acquisitions

Development
#1

Hi,

In order to acquire experiments I often just use the code equivalent of running MDAs, that is to say SequenceSettings passed to the AcquisitionManager and run a non blocking acquisition.

I think I always observed that the system state cache corresponding to the beginning ot the acquisition is re-applied at the end, meaning if property P is in state 0 at the beginning, it will be set to state 0 at the end (if it has changed during the acquisition).

In the context of localization microscopy, I am now facing a situation in which we automatically change a certain property during acquisition (activation laser pulse length) but want to keep it at the same level for the next acquisition. Any insights on how to prevent the system from rolling back to the initial state?

My only solution would be to not do MDA-like acquisitions but rather snap the images and add them to the datastore. This brings me to another question, I guess that when using the SnapLiveManager the images are not pushed to the core circular buffer? (that’s where our activation thread pulls the frames from)

Finally, one of the reason why I’d rather use the MDA than the snap/store approach is that the latter used to be very slow comparitvely. I must admit I haven’t tested it since MM2-gamma was first out, so I might now be wrong.

Thanks!

#2

The newer acquisition engine, AcqEngJ, doesn’t do this. It’s not integrated with MM MDA yet, but you can probably accomplish the same thing through Micro-Magellan (GUI) or Pycro-Manager (scripts)

#3

Hi Joran,

Are there problems re-applying the property after the acquisition ended and the acquisition engine did its restoration from cache? Not elegant for sure, but appears to be easy.

The basic difference between snapping images and running a “streaming” acquisition is that different modes of the camera are used. When snapping, there will be a delay in between snaps to readout the data from the camera, transfer them to the computer, do some stuff with the data there, and wait for the camera to be ready for the next snap. None of that happens in streaming (sequence) mode. The acquisition engine contains heuristics to use sequence mode whenever possible.

You can run sequence mode yourself too. This script (https://nicost.github.io/I2K-MM/mm_api_b.html#/7/0/0) from the I2K Micro-Manager tutorial probably has all you need to get going with that approach.

#4

Thanks a lot for your answers!

I realise I actually starred the AcqEngJ a long time ago, but never got the chance to dive into it. Out of curiosity, what is the priority level of its integration into the MDA pipeline?

The acquisition I was working on right now is part of the plugin we’ve been using for years on our microscope. Unfortunately I don’t have time for a rewrite of any substantial part of the plugin right now, so I just tagged the AcqEngJ as a future direction for its acquisition system.

Nico’s sequence mode did the trick for now!

#5

Good, glad to hear it. I don’t have the bandwidth to do the integration myself, so I think the priority will depend on whoever is actually going to do the work