Off by one error with ASI MS2000 fast sequencing?

Hi All,

I’m attempting to use the fast sequencing capability of our MS-2000 stage with piezo z with the multi dimensional acquisition utility. I have an Orca Fusion triggering the stage using the exposure setting for output triggers, firing on readout end with positive polarity. After acquiring a single Z stack and arming the fast sequence mode, the acquisition proceeds but the resulting data seems to show the stage taking one fewer z step than it should each volume, resulting in the z stack shifting by one slice each time point. Has anyone encountered this before or are there any likely culprits to this behavior?

Thank you!

Is this using the ASI stream function or the triggerscope?


ASI stream! Triggerscope control works properly as far as I can tell, but this is incompletely implemented at the moment.

Which suggests that the problem is likely my trigger configuration from the camera.

It is not inconceivable that the camera sends one extra TTL pulse. This would result in the ASI stage doing one extra “step”, i.e. move to the second position of the “next” sequence. The nicest way to visualize these type of issues is with a logic analyzer such as those by Saleae (

The Saleae device is helpful. I’ve borrowed Nico’s before. You could start debugging using other components that can be triggered. Does this happen only with the z stage, or do you also get one missing trigger if you sequence lasers or XY positions? If it’s everything, then maybe the camera does not send a full TTL for the first frame. I sort of recall that Andor cameras had this issue in one particular mode, because the first frame would begin during a “keep clean” cycle or something like that.

It is also possible that there is a reflection in the cable or connectors, which appears as extra pulses. Is there a splitter or something in the coax? I’ve had issues when using multiple cameras and not using an OR gate or if the “slave” camera is not turned on (when triggering one camera with another). But not really sure why this would only cause one fewer step.

The best solution might be to implement Austin’s great TriggerScope, which it sounds like you already have.


Thanks Sam, the long term plan is definitely to orchestrate with the Triggerscope, but I was exploring fast sequencing since it’s out-of-the-box and wanted something in the interim while I get my Triggerscope scripting set up properly. Very much looking forward to the updated device adapter!

In this case, the setup is as simple as it can be, a single camera triggering the stage directly with no extra logic, splitters, adapters, etc in the way. I’ll see if I can use the Triggerscope itself to count the pulses coming from the camera, hopefully that will narrow things down.

It is possible that something odd is happening on the ASI side as well, although multiple people have used the fast sequencing capability without problems.

I concur that watching the pulses coming from the camera and from the MS-2000 controller is the correct next step. You can probably do it with an oscilloscope too. Easiest to make the stack only a few slices for debugging.

If you email me a problem report text file I’m happy to take a look to see if the ASIStage device adapter is doing anything obviously wrong.

Can confirm that the problem seems to be one extra pulse from the camera by counting TTL using the Triggerscope (don’t have a logic analyzer or O-scope easily available right now). Here is the trigger setup on my camera. I have Output 1 going to the MS-2000 and Output 2 going to the Triggerscope. I’ve also attached a problem report that includes a first stack to load the sequence, then a second 3 volume acquisition with the sequence armed.Problem Report.txt (378.5 KB)

Do you have the camera connected on trigger output 0, 1, or 2? Output 0 is set to be high, except at the start of each exposure, when it goes low for 1 ms, output 1 and 2 are low except when the camera is exposing (which is usually what you want).

Hi Nico,

I have the camera trigger output 1 going to the stage and output 2 going to the Triggerscope, which is where I’m counting the pulses using a long exposure and watching the trigger input LED. Each stack is supposed to be 9 slices but I see 10 flip flops on the Triggerscope, which matches the extra frame problem with the fast sequence on the MS-2000. Output 0 isn’t connected to anything currently, but will be used to blank our laser combiner until I get my acquisition scheme fully implemented on our Triggerscope.


Hi @pavak_shah, I’m glad you identified the root cause.

Here’s a potential work-around: add one extra point to the ASI controller’s ring buffer, using the property SerialCommand (can be done from a script or from the device property browser; for the ASIStage device adapter that property is part of the XYStage device).

Your stack in the Problem Report goes from position 31um to 15um in 2um steps. Use the following command to repeat the last position (Z is the axis letter, and controller units are 10ths of microns):

LD Z=150

It appears from the Problem Report that the ring buffer points are sent when UseFastSequence is set to “Armed”, so you should send this command after setting UseFastSequence but before initiating the acquisition.

If this issue turns out to be common, I could add a feature to the device adapter which would add an extra point automatically when a property is set.

Hi Jon,

Adding the extra slice works so the culprit does seem to be an extra pulse from the camera.


While adding an extra slice has fixed this issue, I’m noticing that when sequencing or fast sequencing is enabled on the stage controller, one of the two channels is written into the datastore in reverse Z order. This behavior does not occur with sequencing off on the stage. Any ideas what might be causing this?

What is the order in your acquisition (i.e., channel-zStack or zStack-channel)? Also, what exactly does “written into the datastore” mean? Does MM show the “upper” image when you set it to show the “lower” one, or is this after opening in Fiji or similar?

Hi Nico, I think I figured things out this morning. What looked like reverse order to me turned out to be missing frames in the stack from one camera due to triggering business. I’m detailing a reply to my own post to clarify what I learned. Sorry!

another note here- I thought I was running in to the same problem with a similar configuration after moving from 1.4 to 2.0gamma. In my case, it turns out that a call to mmc.stopSequenceAcquisition() at the end of each stack was resetting the position in the ring buffer. In my previous 1.4 code, this was tolerated somehow, but it’s not any more!

Full disclosure: the 2.0gamma code was running on a different rig (same part numbers), so it is possible that a firmware update in the camera or the MS2000 controller is at play here too.