Keeping LED on during z stack

[CedricEsp]

Hi, In micro-manager there is an option to keep shutter open during a z-stack, is it possible to do that in napari-micro/pymmcore? Otherwise the LED is turn on and off which slightly slow down the acquisition.

Thanks!

Edit, Doing some digging I found that is a know things to add: https://github.com/pymmcore-plus/useq-schema/issues/38

However, is there a way to programmatically added to an MDA engine?

[tlambert03]

I believe, (but am not sure/have not tested) that you would need to use mmc.setAutoShutter(False), and then manually open/close the shutter before/after the Z-stack.

https://github.com/pymmcore-plus/useq-schema/issues/38 would simply be the declarative form of that (i.e. instructing an mda engine to do so, but not actually telling it how to).

i think short term solution would require you to modify the pymmcore-plus engine (agree @ianhi?)

"ideal" long-term steps here would be:

1. add the directive to useq-schema somewhere
2. honor the directive within our default mda engine

[CedricEsp]

Thanks @tlambert03 it works very well, however it doesn't seem to be the reason why the z-stack was quite "slow". So if I run something like that:

for i, z_pos in enumerate(z_stack_pos):
            
            self._mmc.setPosition(zdev, float(z_pos))
            #need to wait for the device or it doesn't work properly
            self._mmc.waitForDevice(zdev)
            self._mmc.snapImage()
            data[i, :, :] = self._mmc.getImage()

It goes extremely fast While if do the same z stack using the multi-D acquisition, it goes significantly slower (sorry I don't have exact number), is there a particular reason for that?

Thanks!

[ianhi]

i think short term solution would require you to modify the pymmcore-plus engine (agree @ianhi?)

I think so.

While if do the same z stack using the multi-D acquisition, it goes significantly slower (sorry I don't have exact number), is there a particular reason for that?

I wonder if some of the callbacks hooked up to the emit are slowing you down. Can you try running that loop with napari closed? That way you could see if the slowness is coming from napari-micromanager or something in the engine itself.

It's also possible that there is another component in your system that is being set that takes a awhile to be ready. In your loop you only wait on the z device, but if your XY stage has slow communication then I could see these lines: https://github.com/pymmcore-plus/pymmcore-plus/blob/1587c141ede9f488ad4aa2ce04af4b8687904fb6/pymmcore_plus/mda/_engine.py#L213-L222 and the subsequent wiatForSystem slowing things down.

[tlambert03]

Another thing to mention here is that we haven't optimized for "sequenceable" hardware in pymmcore plus's mda engine yet.

I'm curious: Are you by chance comparing to the speed you see in micromanager itself? I would, in some cases, still expect it to be faster than pymmcore-plus

[CedricEsp]

Thanks so much for all your answers! Actually, I have to apologies, in the case of the loop, I had setup a small ROI before the acquisition which (obviously?) made it much faster. Actually, with same the same frame size the MDA is slightly faster than the loop. @ianhi I didn't notice any difference in speed with or without napari-micromanager. @tlambert03 if anything, micromanager seems slower than napari-micromanager.

[tlambert03]

Great! I'll take that 😂

[tlambert03]

closing this since it seems to be mostly resolved. the ultimate underlying issue here is https://github.com/pymmcore-plus/useq-schema/issues/38