Multi-D acquisition snaps imges while Thorlabs FilterWheel FW102C is moving

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Multi-D acquisition snaps imges while Thorlabs FilterWheel FW102C is moving

luyan
Hi there,

I am running MM1.4 64-bit nightly built. I have a Thorlabs motorized filterwheel FW102C. As I set up the 'Channel' in the multi-D acquisition, (no matter the order) the camera seems completely ignore the filterwheel, and snapped images as the filterwheel is moving, i.e. it didn't wait till the filter is in position, and they seems not synchronized at all.

I have researched posts in the past, but did not find much information on similar issue. So I was wondering if someone could point me a direction to look into?

Thank you very much,
Lu
Reply | Threaded
Open this post in threaded view
|

Re: Multi-D acquisition snaps imges while Thorlabs FilterWheel FW102C is moving

JonD
Administrator
Hi Lu,

luyan wrote
I am running MM1.4 64-bit nightly built. I have a Thorlabs motorized filterwheel FW102C. As I set up the 'Channel' in the multi-D acquisition, (no matter the order) the camera seems completely ignore the filterwheel, and snapped images as the filterwheel is moving, i.e. it didn't wait till the filter is in position, and they seems not synchronized at all.

I have researched posts in the past, but did not find much information on similar issue. So I was wondering if someone could point me a direction to look into?
When the MDA changes the channel or interacts with any other device, it will make sure that the device reports that it's not busy before proceeding with the acquisition.  

A quick look at the device adapter source code reveals that the filterwheel isn't queried to see whether it still busy.  Instead it reports not busy after a specified delay time has passed since the position was last set.  I believe you can specify this delay for the device towards the end of the hardware config wizard and it probably defaults to 0.  Try setting it to 1000ms or something like that.

It's clear that the device adapter code was based on the demo device code.  it isn't provided by the manufacturer.  If there is a way to query the hardware itself to see whether it is busy moving, then the device adapter code could be improved.

Jon

-------------------------------------------
Jon Daniels
Applied Scientific Instrumentation
29391 West Enid Rd, Eugene, OR 97402
Phone: (541) 461-8181 x118
-------------------------------------------
Reply | Threaded
Open this post in threaded view
|

RE: Multi-D acquisition snaps imges while Thorlabs FilterWheel FW102C is moving

luyan
This post has NOT been accepted by the mailing list yet.

Hi Jon,

 

Thanks much for your reply.

 

I set the delay, and it seemed working properly.

 

I am familiarizing myself with c++ so that I can debug the issues in the future.

 

By looking at the filterwheel manual, there seems no status query command available:

 

The closest I can think of is the Get Position ‘pos?’, maybe it will return only when the wheel reaches the set position. But I don’t know yet how to add this into the adapter source code. So if this command should work, then would it be a simple fix or it may take some time to do based on your experience? Just wanted to know what I should expect J.

 

Thank you very much again,

 

Lu

 

 

 

 

From: JonD [via Micro-Manager] [mailto:ml+[hidden email]]
Sent: Wednesday, August 02, 2017 8:39 AM
To: Yan, Lu
Subject: Re: Multi-D acquisition snaps imges while Thorlabs FilterWheel FW102C is moving

 

Hi Lu,

luyan wrote

I am running MM1.4 64-bit nightly built. I have a Thorlabs motorized filterwheel FW102C. As I set up the 'Channel' in the multi-D acquisition, (no matter the order) the camera seems completely ignore the filterwheel, and snapped images as the filterwheel is moving, i.e. it didn't wait till the filter is in position, and they seems not synchronized at all.

I have researched posts in the past, but did not find much information on similar issue. So I was wondering if someone could point me a direction to look into?

When the MDA changes the channel or interacts with any other device, it will make sure that the device reports that it's not busy before proceeding with the acquisition.  

A quick look at the device adapter source code reveals that the filterwheel isn't queried to see whether it still busy.  Instead it reports not busy after a specified delay time has passed since the position was last set.  I believe you can specify this delay for the device towards the end of the hardware config wizard and it probably defaults to 0.  Try setting it to 1000ms or something like that.

It's clear that the device adapter code was based on the demo device code.  it isn't provided by the manufacturer.  If there is a way to query the hardware itself to see whether it is busy moving, then the device adapter code could be improved.

Jon

-------------------------------------------
Jon Daniels
Applied Scientific Instrumentation
29391 West Enid Rd, Eugene, OR 97402
Phone: (541) 461-8181 x118
-------------------------------------------


To unsubscribe from Multi-D acquisition snaps imges while Thorlabs FilterWheel FW102C is moving, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

RE: Multi-D acquisition snaps imges while Thorlabs FilterWheel FW102C is moving

JonD
Administrator
This post has NOT been accepted by the mailing list yet.
Hello Lu,

luyan wrote
By looking at the filterwheel manual, there seems no status query command available:

The closest I can think of is the Get Position 'pos?', maybe it will return only when the wheel reaches the set position. But I don't know yet how to add this into the adapter source code. So if this command should work, then would it be a simple fix or it may take some time to do based on your experience? Just wanted to know what I should expect :).
Having zero knowledge of this particular filterwheel but experience with other motion control firmware, I doubt that 'pos' command would behave that way.  But you could contact the manufacturer to ask.  If there is some way to tell that the wheel reached the target position then someone can help you figure out the appropriate C++ code edit.

As a general principle, the more you care about maximizing speed the more effort you should put into using hardware TTL triggers.  In this case the high-level software like Micro-manager isn't in the the critical timing paths but initiates the acquisition and then listens for images.  Many microscope hardware devices can be made to work with triggers, and Micro-manager does too.  It appears that this filterwheel can give an output trigger, presumably when it finishes its move.

Jon

-------------------------------------------
Jon Daniels
Applied Scientific Instrumentation
29391 West Enid Rd, Eugene, OR 97402
Phone: (541) 461-8181 x118
-------------------------------------------