top bar

Difference between revisions of "Hardware-based Synchronization in Micro-Manager"

Line 20: Line 20:
* [[ESIOImagingControllers]] -- AOTFs (laser combiners) and piezo focus drives
* [[ESIOImagingControllers]] -- AOTFs (laser combiners) and piezo focus drives
* [[Marzhauser]] (TANGO controller) --  Märzhäuser piezo focus drive
* [[Marzhauser]] (TANGO controller) --  Märzhäuser piezo focus drive

Revision as of 11:52, 26 September 2013

Hardware synchronization


Computers have limits in their ability to synchronize equipment. Since the commonly used operating systems are not "real time" there is never a guarantee that a task will be executed within a certain time frame. To achieve that tightest and fastest synchronization possible you will therefore need to synchronize the equipment electronically.

Many microscope hardware components have inputs and outputs for TTL signals (see our Micro-Manager tutorial) that can be used for synchronization. These TTLs are usually physically connected by BNC connectors. There are many different ways of wiring up these control signals, one could - for instance - have a micro-controller device that knows all the delays in each of the components and that triggers each at just the right time.


Although such setups are possible in Micro-Manager, we decided to provide general support for a simpler scheme. Micro-Manager has build-in support for for a wiring setup in which the camera is the controller driving all other equipment, i.e. the camera is the clock. So, the trigger out signal of the camera (which should go high whenever the camera is exposing and go low whenever the camera is not exposing) is connected to the trigger input of the device.

Micro-Manager will need to know about this configuration. It learns about this through the device adapted code. Several device types can support triggering, at the moment these are: (piezo Z) stages, XY-stages (although most XY stages will be too slow for this approach), digital to analogue converters (DA), and any property of any device. The device will indicate through the Micro-Manager API whether or not it supports triggering (we use the term "Sequences"). Usually, the device will have a property through which the user can switch the use of sequences on and off. Examples for device adapter developers how to write code for sequencable devices can be found in the Arduino device adapter code.

The Micro-Manager acquisition engine will always try to use triggers to execute an acquisition. For instance, if it is running a Z-stack using a triggerable piezo Z drive, it will upload a sequence of the desired Z-positions to the piezo Z-drive controller, tell the camera to take a sequence of the desired number of images and rely on the hardware triggering for Z-control. It will interpret the images coming from the camera correctly and present them as a Z-stack. Likewise, if your channel configuration only switches a triggerable property (for instance, selection of a laser line through an AOTF controller), it will load the sequence of AOTF states to the controller and rely on the hardware triggering to switch channels. The nest result is image acquisition that is only limited by the speed of the camera, whereas nothing changes for the end user, i.e., they use the normal way to indicate their MDA strategy.

Controller devices that currently support triggered sequences

© Micro-Manager : Vale Lab, UCSF 2006-2011 | All Rights Reserved | Contact