Writing a sequenceable adapter

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

Writing a sequenceable adapter

nanthony
I'm working on a device adapter that uses hardware triggering via
micromanager's property sequence functionality.

I haven't found much documentation on this but from looking through the code
it seems like there are two separate ways to do this. I'm wondering if there
is a recommended approach and if there are any drawbacks to doing it one way
or the other.

1: Implement the `IsPropertySequenceable()`,  `StartPropertySequence()`,
etc. methods. Each method must check the provided property name to determine
how to properly handle sequencing.

2: In the `On{PropertyName}()` method implement handling for cases where the
provided `MM::ActionType` is `ActionType::isSequenceable`,
`ActionType::startSequence`, etc.

Is my understanding here correct?

Thanks,
  Nick




--
Sent from: http://micro-manager.3463995.n2.nabble.com/


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Writing a sequenceable adapter

Stuurman, Nico
HI Nick,

> I'm working on a device adapter that uses hardware triggering via
> micromanager's property sequence functionality.
>
> I haven't found much documentation on this but from looking through the code
> it seems like there are two separate ways to do this. I'm wondering if there
> is a recommended approach and if there are any drawbacks to doing it one way
> or the other.
>
> 1: Implement the `IsPropertySequenceable()`,  `StartPropertySequence()`,
> etc. methods. Each method must check the provided property name to determine
> how to properly handle sequencing.
>
> 2: In the `On{PropertyName}()` method implement handling for cases where the
> provided `MM::ActionType` is `ActionType::isSequenceable`,
> `ActionType::startSequence`, etc.
>

I'll have to look at the code and documentation again to remember, but
first of all, what type of device do you want to make sequenceable
(camera, stage, statedevice?)

Best,

Nico

_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Writing a sequenceable adapter

nanthony
Nico Stuurman-2 wrote
> I'll have to look at the code and documentation again to remember, but
> first of all, what type of device do you want to make sequenceable
> (camera, stage, statedevice?)

Thanks Nico,

It is a tunable filter so I am planning on making the `Wavelength` property
sequenceable for faster operation. Ultimately I'll probably be making a
couple adapters with wavelength sequencing but for now I'm working on a
Varispec LCTF.

It didn't seem like any of the more specific base classes fit well so right
now I just have in inheriting from CGenericDevice.

--Nick



--
Sent from: http://micro-manager.3463995.n2.nabble.com/


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Writing a sequenceable adapter

Stuurman, Nico
In reply to this post by nanthony
Hi Nick,

> I'm working on a device adapter that uses hardware triggering via
> micromanager's property sequence functionality.
>
> I haven't found much documentation on this but from looking through the code
> it seems like there are two separate ways to do this. I'm wondering if there
> is a recommended approach and if there are any drawbacks to doing it one way
> or the other.
>
> 1: Implement the `IsPropertySequenceable()`,  `StartPropertySequence()`,
> etc. methods. Each method must check the provided property name to determine
> how to properly handle sequencing.
>
> 2: In the `On{PropertyName}()` method implement handling for cases where the
> provided `MM::ActionType` is `ActionType::isSequenceable`,
> `ActionType::startSequence`, etc.

The Device interface is defined in MMDevice/MMDevice.h.  The functions
that you mention in approach #1 are defines as virtual, hence need to be
re-defined (overridden) by derived classes.  To facilitate things,
DeviceBase.h (from which you likely inherit, although you do not
absolutely need to do this) has implementations for these functions,
which all call into MM::Property. MMDevice/Property.h (and cpp) define
several things that enable approach #2.  So, approach #2 should be
easier, need less code, and allow for changes to be made in one place
(DeviceBase.h and/or Property.h/cpp), so is preferable.
>>   what type of device do you want to make sequenceable
>> (camera, stage, statedevice?)
>>
> It is a tunable filter so I am planning on making the `Wavelength` property
> sequenceable for faster operation. Ultimately I'll probably be making a
> couple adapters with wavelength sequencing but for now I'm working on a
> Varispec LCTF.


Wavelength changers kind of warrant their own device interface.  I
assume that you will end up acquiring many channels, each with its own
wavelength.  ImageJ has a limitation of something like 8 channels, I am
not sure if MM (2.0-gamma) still has that same issue.  Setting up an MDA
with many channels is cumbersome, but I guess that you can do so in a
script. So, for the time being, I agree that  your best choice is to
make this a generic device.

Best,


Nico





_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Writing a sequenceable adapter

nanthony
Thanks,

Approach 2# seems like the way to go then.

I looked at it a bit and you're right that the MDA isn't set up very well
for doing this type of thing with channels. I may end up doing this through
a plugin that inserts a runnable.

One thing I noticed that doesn't seem right is that the MDA doesn't allow
for `Channels` to be anything other than the slowest changing parameter. For
example, you can do a "Position, Time, Channels" acquisition or a
"Time,Position,Channels", but you can't do "Position, Channels, Time", or
"Channels, Position, Time"



--
Sent from: http://micro-manager.3463995.n2.nabble.com/


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Writing a sequenceable adapter

Stuurman, Nico

> Approach 2# seems like the way to go then.

Agreed.

> I looked at it a bit and you're right that the MDA isn't set up very well
> for doing this type of thing with channels. I may end up doing this through
> a plugin that inserts a runnable.

Alternatively, you could write a script to run the complete acquisition.

> One thing I noticed that doesn't seem right is that the MDA doesn't allow
> for `Channels` to be anything other than the slowest changing parameter. For
> example, you can do a "Position, Time, Channels" acquisition or a
> "Time,Position,Channels", but you can't do "Position, Channels, Time", or
> "Channels, Position, Time"

Correct.  To fix this, one would need to change the acquisition engine
code (or write a new acquisition engine).   Both daunting propositions...


Best,

Nico



_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|

Re: Writing a sequenceable adapter

Karl Bellve-3


On Wed, Oct 24, 2018 at 1:18 AM Stuurman, Nico <[hidden email]> wrote:

> Approach 2# seems like the way to go then.

Agreed.

> I looked at it a bit and you're right that the MDA isn't set up very well
> for doing this type of thing with channels. I may end up doing this through
> a plugin that inserts a runnable.

Alternatively, you could write a script to run the complete acquisition.


This is exactly what I do with the ITC18 adapter, which predates the hardware sequence API. Take look at: https://micro-manager.org/wiki/ITC18

The ITC18 adapter loads a sequence from an "imaging protocol" file. I then use µManager bean shell scripts to "teach" µManager about what is coming in, channels, etc..

I generate the "imaging protocol" file with external scripts. I can generate very complex imaging protocols independently of µManager. This system has worked out well for us. 


Cheers Karl

Karl Bellvé

Biomedical Imaging Group
Molecular Medicine
University of Massachusetts Medical School


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general