MDA freeze (suspect Triggerscope parameters)


I have a group called ‘Channels’ which contains all my presets for switching between modalities and wavelengths (TIRF, FRAP, & GFP, mCherry, etc). I am using the Triggerscope with Nico’s firmware (which greatly simplifies setting TTL lines), but even with the reduced number of parameters in the group I am still having issues with the MDA lagging when trying to add and remove channels.

To be specific I have 28 parameters within the ‘Channel’ group to be able to set all the different presets on the system.

Any help welcome.

Triggerscope 3B for clarity.

Can you share your config file?

Also, what exactly do you mean with “MDA lagging when trying to add or remove channels”? Do you mean the MDA dialog being slow to respond, or do you mean that the MDA runs slower then you expect (but then, what does that have to do with adding or removing a channel)?

Just wanted to jump in and offer assistance. Let me know if you think this is hardware related Nico!


Hi Nico,

I have attached the config file (with *.txt as it didn’t let me with *.cfg)TestConfig.txt (39.2 KB) .

Sorry I wasn’t clear. I mean I have enabled channels as part of the MDA and then I select my channel group ‘Channel’ and then during the process of trying to configure the presets to use the MDA stops responding to mouse clicks. So cliking on ‘new’, ‘remove’, ‘exposure’, ‘use?’, etc do nothing. This is all prior to running the MDA acquisition. In some instances it will eventually respond after leaving it a minnute or so.

Example -


Just as a check: when you use the demo configuration you do not see this delay?

If so, then it does sound like the large number of properties in your groups contribute to this. I am wondering if you could use a much simpler configuration, but will need to look at your config in more detail before I can advice. It would also be helpful if you would generate and send a trouble report (Help > report a Problem) from such an episode of slow response.

I am have been running on the MM-2-gamma 20201013 build. I have tested it with a demo config and only including 4 parameters in the group and get the same issue. This should mean we can exclude hardware related issues.

I have subsequently started running the most recent build 20210127. I have tested this with the demo config and seems to work fine in the most recent build. I haven’t tested it yet on the proper hardware config, but will let you know if I run into any issues.

I also submitted a trouble report as you suggested from when I was using the older build.

All working in the latest build with my main config as well now with all the parameters included.

Looks to be have been build related, would be my guess…

Still promised you some comments on the configuration. In general, it is beneficial to keep the channel definition as short as possible. Each of the properties in the channel definition will be set, most often resulting in (serial) communication to the device, hence causing delays and potential for errors.

So, properties in the channel group that are the same in all configurations should be removed (for instance: “Blank on”, “Blanking” (although this seems on for one channel, is that on purpose?). Also, it is never a good idea to switch light sources by setting their state property directly. Rather, create a shutter associated with the device (using the Utilties adapter), and use only the Core-Shutter property in your configuration. You should also not need to add all the DAC voltages once you have a shutter device included, even when the DAC voltage is set to a constant, the actual voltage will be 0 as long as the shutter is closed. Such a configuration will result in significantly less chatter with the devices and better performance.

Of course, I may be missing something since I do not know anything about your microscope system, but most often these types of configurations result from a lack of understanding the (virtual) shutters available in MM and the advantages of using the auto-shutter concept. Clearly, we should do a better job at explaining, but I hope you can help!

I’ll commit to making some example configuration Youtube videos covering these options.
To be honest sometimes I even have a hard time remembering the optimal configuration for a given setup!!


Thanks for the feedback Nico! To address some of your points:

  1. I agree that “Blank on” can go as that will always be set as ‘Low’ regardless of the preset.

  2. Sorry that was an old version I was modding. The majority of channel presets will have “Blanking” set to “On”, but some will have it “Off”.

  3. If you set the TriggerScope TTL device as the “State Device” property of the “State Device Shutter”, can you then define the TTL1-8 and TTL9-18 states? I have 4 different light sources with 12 different wavelengths in total. This equates to 12 individual TTL lines to address the different exposure times for each wavelength. The current setup is using the ‘expose out’ from a camera to input pin 1 on the TriggerScope to give the timing signals to control the on/off timing of the different light sources, where the choice of wavelength would be determined by the TTL1-8 and TTL9-18 states. If I can use a single shutter that would be my preference, but wasn’t sure it was possible under the circumstances. This may just be me misunderstanding of how it should be implemented.

  4. The DAC voltages are used to control the intensity of the different light sources. My intention with this was to have a intensity preset for each wavelength, but essentially this could be removed from the group as this can just be set within the main control window under configuration settings.

  5. Lastly I would be more than happy to help anyway I can. I will need to put some documentation together for others I’m working with who will need to get to grips with this, so happy to share.


Per my previous email I’ve recorded a video on configuring the Triggerscope-MM code, and setting things up at a basic level in Micro-Manager. I hope this helps!


Hi Austin,

Can you try the blanking with the TTL states based on using Nico’s TriggerScope-MM version on the nightly build 20210127? The blanking doesn’t seem to be working now I have moved over to the new nightly build.

Just want to make sure it is defintely not a hardware issue and is related to a nightly build/device adapter issue?

I am currently using ‘expose out’ from Photometrics camera into Trig-1 input and have a LED gate input connected to TTL-1. Under properties in Micromanager I have the following settings:

  1. TTL 1-8 Blank On = ‘Low’
  2. TTL1-8 Blanking = ‘On’
  3. TTL1-8 State = ‘1’

TTL-1 is going high (5v) independent of the Trig-1 input signal. So essentially the LED is on all the time even when the camera is not live. I have tried this same setup with other light sources (lasers, etc) with the same result.

Hi @andrewallan5,

I can not reproduce the issue using the current version (20210204) of Micro-Manager. This is on a Triggerscope V-3B with the current MM firmware. Following your 3 steps, output only goes high when the input is high (as intended). Are you using the same Triggerscope with the same firmware?

B.t.w., it may be better to move this to a new topic.