AdvancedImagingUTSW
commented
2 hours ago Here is an example of a per channel z-stack acquisition.
Open AdvancedImagingUTSW opened 2 hours ago
AdvancedImagingUTSW
commented
2 hours ago Here is an example of a per channel z-stack acquisition.
Overview As part of the UTD Capstone project, our goal is to simplify the optoelectronics of the microscope. Currently, we often have stage controllers, filter wheel controllers, an NI DAQ card, piezo controllers, etc. Each one of these things has to be independently wired up. This serves as an impediment for non-experts, slows adoption, and increases the likelihood that mistakes will require significant debugging.
Requirements The microscope requires synchronous delivery of a number of analog and digital waveforms, serial commands, DLL calls, etc. Regarding the analog/digital control, we require:
Waveform type: triangle/sawtooth/sine/DC. Should enable control of amplitude, offset, phase. Waveform duration: Camera exposure + readout time + any user added delays.
A standard operational workflow is to: Queue waveforms on galvos 1…N Queue waveforms on remote focusing device. Queue dc waveform for analog output of laser. Can be a vector of voltages, or a single voltage value. Queue digital output of laser. Queue external trigger of camera. Camera is edge triggered. Software triggers all queued waveforms, causing them to roll off the device synchronously.
In a per-stack acquisition mode, where an entire channel is acquired for CH0, then CH1…, we would want to repeat this output for every image slice. In a per-z acquisition mode, where image slices are acquired in a channel interleaved fashion (CH0, CH1, step in z…), I would want to adjust the waveforms according to the user-specified settings (amplitude, offset, etc.) on a per-slice basis.
I’m not sure what the rate-limiting steps of such a process would be. For NI cards, writing the waveforms to the card are our slowest step. Thus, the per-z acquisition mode is frustratingly slow since we write data to tasks for every image. I have ideas on how to fix this, but I will see wha you come up with.
Your job is to figure out how we can consolidate it, while ensuring that setting it up remains easy and obvious. One apparent solution is to use ASI's Tiger Controller, but other options are welcome too. Should you choose to proceed with this manufacturer/system, some information is below.
Tiger Controller The Tiger controller has 16 certain number of physical slots -- some cards occupy 2 slots -- and the "easy" addresses 0-9. If you need more physical slots then you can daisy-chain controllers. If you need more than 10 cards then there is an "extended address" space that is slightly more cumbersome to access but very doable, supported in Micro-Manager, etc. One limitation is that each axis gets a letter and we only have A-Z (each motor is an axis, the PLC is one axis, etc.)
ASI Cards TGDAC4 has 4 analog outputs. It does support some form or arbitrary waveforms with 250 points (and maybe extendable slightly more). It also supports repeating patterns like sawtooth/sine. It is 16 bit and has a 4kHz update rate.
TGPLC is 8 digital I/O ports. It does not currently support arbitrary waveforms but there is the possibility that it could be implemented. Due to hardware it would probably be able to get something like 1k or maybe up to 4k arbitrary points but not nearly what the NIDAQ cards achieve. 4kHz max update rate. For standard operation, this device pretty much supports ON/OFF gating, which can be used to execute pretty sophisticated triggering routines. Some examples of this can be found as a plugin to MicroManager (see the latest build). The PLC can also be setup using pymmcore_plus based off scripts at the bottom of the docs page.
TGDAC. Used to control a piezo for fast z-scanning.
TGFW. Used to control filter wheels.
TGDCM2. Used to control two stage axes.