Objective changing after MDA

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

Objective changing after MDA

Kevin Yamauchi
Hello!

We are experiencing an issue where at the end of a multidimensional acquisition (autofocus, z slices, multiple positions, multi-channel), the objective will switch to a different objective. In our tests, we seem to only be able to reproduce the behavior when we use the "Oughtafocus" autofocus plugin (i.e., when  we use other autofocus plugins, the objective does not switch at the end of an MDA). When I checked the log file (full log attached, snippet below), it appears that the command to switch objective is sent during the "cleanup".Do you have any advice on how to prevent the objective from switching following the completion of the MDA?  Is there some sort of default objective setting that we set accidentally? Thank you in advance!

A bit about our system:
  • Micromanager: 1.4.23
  • Microscope: Leica DMi8
CoreLog snippet below. Here we performed an MDA using the 20x objective (multiple channels, multiple positions, multiple z slices, "Oughtafocus") and at the end of the acquisition, the microscope switched to the 10x objective.

2019-12-05T13:44:56.731706 tid3788 [dbg,App] [AE] END acquire
2019-12-05T13:44:56.731706 tid3788 [dbg,App] [AE] ##### END acquisition event
2019-12-05T13:44:56.732703 tid3788 [dbg,App] [AE] cleanup
2019-12-05T13:44:56.739679 tid3788 [dbg,App] [AE] <-- (. org.micromanager.mm/mmc isSequenceRunning)
2019-12-05T13:44:56.739679 tid3788 [dbg,App] [AE] --> false
2019-12-05T13:44:56.744684 tid3788 [dbg,App] [AE] <-- (. org.micromanager.mm/mmc getSystemStateCache)
2019-12-05T13:44:56.745688 tid3788 [dbg,App] [AE] --> #<Configuration mmcorej.Configuration@6111b1b0>
2019-12-05T13:44:56.753661 tid3788 [dbg,App] [AE] <-- (. org.micromanager.mm/mmc waitForDevice "Zyla 4.2")
2019-12-05T13:44:56.753661 tid3788 [dbg,Core] Waiting for device Zyla 4.2...
2019-12-05T13:44:56.753661 tid3788 [dbg,Core] Finished waiting for device Zyla 4.2
2019-12-05T13:44:56.754653 tid3788 [dbg,App] [AE] --> nil
2019-12-05T13:44:56.756646 tid3788 [dbg,App] [AE] <-- (. org.micromanager.mm/mmc setProperty "Zyla 4.2" "TemperatureStatus" "Not Stabilised")
2019-12-05T13:44:56.756646 tid3788 [dbg,Core:dev:Zyla 4.2] Will set property "TemperatureStatus" to "Not Stabilised"
2019-12-05T13:44:56.756646 tid3788 [dbg,Core:dev:Zyla 4.2] Did set property "TemperatureStatus" to "Not Stabilised"
2019-12-05T13:44:56.757649 tid3788 [dbg,App] [AE] --> nil
2019-12-05T13:44:56.758650 tid3788 [dbg,App] [AE] <-- (. org.micromanager.mm/mmc waitForDevice "Zyla 4.2")
2019-12-05T13:44:56.758650 tid3788 [dbg,Core] Waiting for device Zyla 4.2...
2019-12-05T13:44:56.758650 tid3788 [dbg,Core] Finished waiting for device Zyla 4.2
2019-12-05T13:44:56.759644 tid3788 [dbg,App] [AE] --> nil
2019-12-05T13:44:56.761612 tid3788 [dbg,App] [AE] <-- (. org.micromanager.mm/mmc setProperty "Zyla 4.2" "LightScanPlus-ExposedPixelHeight" "1417")
2019-12-05T13:44:56.761612 tid3788 [dbg,Core:dev:Zyla 4.2] Will set property "LightScanPlus-ExposedPixelHeight" to "1417"
2019-12-05T13:44:57.260057 tid3788 [dbg,Core:dev:Zyla 4.2] Did set property "LightScanPlus-ExposedPixelHeight" to "1417"
2019-12-05T13:44:57.261025 tid3788 [dbg,App] [AE] --> nil
2019-12-05T13:44:57.264056 tid3788 [dbg,App] [AE] <-- (. org.micromanager.mm/mmc waitForDevice "ObjectiveTurret")
2019-12-05T13:44:57.264056 tid3788 [dbg,Core] Waiting for device ObjectiveTurret...
2019-12-05T13:44:57.264056 tid3788 [dbg,Core] Finished waiting for device ObjectiveTurret
2019-12-05T13:44:57.265012 tid3788 [dbg,App] [AE] --> nil
2019-12-05T13:44:57.269033 tid3788 [dbg,App] [AE] <-- (. org.micromanager.mm/mmc setProperty "ObjectiveTurret" "State" "0")
2019-12-05T13:44:57.269033 tid3788 [dbg,Core:dev:ObjectiveTurret] Will set property "State" to "0"
2019-12-05T13:44:57.269033 tid3788 [dbg,dev:COM9] SetCommand -> 76022 1\r
2019-12-05T13:44:57.269033 tid3788 [dbg,Core:dev:ObjectiveTurret] Did set property "State" to "0"
2019-12-05T13:44:57.269991 tid3788 [dbg,App] [AE] --> nil
2019-12-05T13:44:57.273017 tid3788 [dbg,App] [AE] <-- (. org.micromanager.mm/mmc waitForDevice "ObjectiveTurret")
2019-12-05T13:44:57.273017 tid3788 [dbg,Core] Waiting for device ObjectiveTurret...
2019-12-05T13:44:57.289926 tid3792 [dbg,dev:COM9] Read <- (hex) 24 37 37 30 33 33 20 30 20 30 0d
2019-12-05T13:44:57.289926 tid3792 [dbg,dev:Scope] $77033 0 0
2019-12-05T13:44:57.322819 tid3792 [dbg,dev:COM9] Read <- (hex) 24 37 31 30 30 34 20 31 20 30 20 30 20 30 20 30 0d
2019-12-05T13:44:57.322819 tid3792 [dbg,dev:Scope] $71004 1 0 0 0 0
2019-12-05T13:44:57.443433 tid3792 [dbg,dev:COM9] Read <- (hex) 24 34 38 30 32 33 20 31 31 31 31 34 2e 30 31 30 30 0d
2019-12-05T13:44:57.443433 tid3792 [dbg,dev:Scope] $48023 11114.0100
2019-12-05T13:44:57.465398 tid3792 [dbg,dev:COM9] Read <- (hex) 24 37 31 30 32 33 20 33 38 33 39 37 36 0d
2019-12-05T13:44:57.465398 tid3792 [dbg,dev:Scope] $71023 383976
2019-12-05T13:44:57.509241 tid3792 [dbg,dev:COM9] Read <- (hex) 24 34 38 30 32 33 20 31 30 37 39 31 2e 32 39 30 30 0d
2019-12-05T13:44:57.509241 tid3792 [dbg,dev:Scope] $48023 10791.2900
2019-12-05T13:44:57.575036 tid3792 [dbg,dev:COM9] Read <- (hex) 24 34 38 30 32 33 20 31 30 34 38 31 2e 33 39 30 30 0d 24 34 38 30 33 39 20 31 20 30 0d
2019-12-05T13:44:57.575036 tid3792 [dbg,dev:Scope] $48023 10481.3900
2019-12-05T13:44:57.575036 tid3792 [dbg,dev:Scope] $48039 1 0
2019-12-05T13:44:57.607929 tid3792 [dbg,dev:COM9] Read <- (hex) 24 37 31 30 32 33 20 32 33 36 39 39 39 0d
2019-12-05T13:44:57.607929 tid3792 [dbg,dev:Scope] $71023 236999
2019-12-05T13:44:57.640829 tid3792 [dbg,dev:COM9] Read <- (hex) 24 34 38 30 32 33 20 31 30 30 39 32 2e 36 39 30 30 0d
2019-12-05T13:44:57.640829 tid3792 [dbg,dev:Scope] $48023 10092.6900
2019-12-05T13:44:57.706617 tid3792 [dbg,dev:COM9] Read <- (hex) 24 34 38 30 32 33 20 31 30 30 30 30 2e 30 30 30 30 0d
2019-12-05T13:44:57.706617 tid3792 [dbg,dev:Scope] $48023 10000.0000
2019-12-05T13:44:57.739490 tid3792 [dbg,dev:COM9] Read <- (hex) 24 37 31 30 32 33 20 37 32 39 38 36 0d
2019-12-05T13:44:57.739490 tid3792 [dbg,dev:Scope] $71023 72986
2019-12-05T13:44:57.882069 tid3792 [dbg,dev:COM9] Read <- (hex) 24 37 31 30 32 33 20 31 39 35 37 0d
2019-12-05T13:44:57.882069 tid3792 [dbg,dev:Scope] $71023 1957
2019-12-05T13:44:57.914964 tid3792 [dbg,dev:COM9] Read <- (hex) 24 37 36 30 30 34 20 31 20 31 20 31 20 30 0d
2019-12-05T13:44:57.914964 tid3792 [dbg,dev:Scope] $76004 1 1 1 0
2019-12-05T13:44:57.925899 tid3792 [dbg,dev:COM9] Read <- (hex) 24 37 31 30 30 34 20 30 20 30 20 30 20 30 20 30 0d
2019-12-05T13:44:57.925899 tid3792 [dbg,dev:Scope] $71004 0 0 0 0 0
2019-12-05T13:44:58.002651 tid3792 [dbg,dev:COM9] Read <- (hex) 24 37 31 30 32 33 20 30 0d
2019-12-05T13:44:58.002651 tid3792 [dbg,dev:Scope] $71023 0
2019-12-05T13:44:58.408390 tid3792 [dbg,dev:COM9] Read <- (hex) 24 37 36 30 30 34 20 31 20 30 20 31 20 30 0d 24 37 36 30 33 33 20 31 20 33 20 31 31 35 30 36 34 31 31 0d
2019-12-05T13:44:58.408390 tid3792 [dbg,dev:Scope] $76004 1 0 1 0
2019-12-05T13:44:58.408390 tid3792 [dbg,dev:Scope] $76033 1 3 11506411
2019-12-05T13:44:58.413374 tid3788 [dbg,Core] Finished waiting for device ObjectiveTurret
2019-12-05T13:44:58.413374 tid3788 [dbg,App] [AE] --> nil
2019-12-05T13:44:58.419353 tid3788 [dbg,App] [AE] <-- (. org.micromanager.mm/mmc setProperty "ObjectiveTurret" "Article Number" "11506411")
2019-12-05T13:44:58.419353 tid3792 [dbg,dev:COM9] Read <- (hex) 24 37 37 30 32 31 20 30 20 30 0d 24 37 37 30 30 34 20 31 20 31 0d 24 37 30 30 32 38 20 31 30 0d
2019-12-05T13:44:58.419353 tid3792 [dbg,dev:Scope] $77021 0 0
2019-12-05T13:44:58.419353 tid3792 [dbg,dev:Scope] $77004 1 1
2019-12-05T13:44:58.419353 tid3792 [dbg,dev:Scope] $70028 10
2019-12-05T13:44:58.419353 tid3788 [dbg,Core:dev:ObjectiveTurret] Will set property "Article Number" to "11506411"
2019-12-05T13:44:58.419353 tid3788 [dbg,Core:dev:ObjectiveTurret] Did set property "Article Number" to "11506411"

Thanks,
Kevin


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

CoreLog20191205T134203_pid5904.txt (720K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Objective changing after MDA

Nico Stuurman-2
On 12/5/19 1:59 PM, Kevin Yamauchi wrote:

> e are experiencing an issue where at the end of a multidimensional
> acquisition (autofocus, z slices, multiple positions, multi-channel),
> the objective will switch to a different objective. In our tests, we
> seem to only be able to reproduce the behavior when we use the
> "Oughtafocus" autofocus plugin (i.e., when  we use other autofocus
> plugins, the objective does not switch at the end of an MDA). When I
> checked the log file (full log attached, snippet below), it appears
> that the command to switch objective is sent during the "cleanup".Do
> you have any advice on how to prevent the objective from switching
> following the completion of the MDA?  Is there some sort of default
> objective setting that we set accidentally? Thank you in advance!
>
> A bit about our system:
>
>   * Micromanager: 1.4.23
>

Source code of the Oughtafocus plugin (for 1.4.23) is here:
https://valelab4.ucsf.edu/svn/micromanager2/trunk/autofocus/OughtaFocus.java

Search for the variable "oldState".  It looks like the fullFocus method
sets that to the state of whatever is in your ChannelGroup. If you
happen to have set a channelgroup in which you have an objective, then
that could explain things.

I guess that the idea is to focus using a specific config-setting, and
to return the system after this was done.  Let me know if this makes
sense with what you observe.




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: Objective changing after MDA

MORRISON Harris
Morning,

I had exactly the same issue this week though not every time. Plus the microscope itself Zeiss Observer Z1) was not communicating the change in objective i.e. the Lens group set in the Main window still showed the original lens for acquisition instead of the one after the change. 

I'll give your suggestion a try, thanks Nico.

H


Harris Morrison

Advanced Imaging Resource (AIR)

MRC Human Genetics Unit

Institute of Genetics and Molecular Medicine (IGMM)

Carrington Crescent,

University of Edinburgh

Crewe Road

EH4 2XU



From: Nico Stuurman <[hidden email]>
Sent: 06 December 2019 02:07
To: Micro-Manager General <[hidden email]>; Kevin Yamauchi <[hidden email]>
Subject: Re: [micro-manager-general] Objective changing after MDA
 
On 12/5/19 1:59 PM, Kevin Yamauchi wrote:
> e are experiencing an issue where at the end of a multidimensional
> acquisition (autofocus, z slices, multiple positions, multi-channel),
> the objective will switch to a different objective. In our tests, we
> seem to only be able to reproduce the behavior when we use the
> "Oughtafocus" autofocus plugin (i.e., when  we use other autofocus
> plugins, the objective does not switch at the end of an MDA). When I
> checked the log file (full log attached, snippet below), it appears
> that the command to switch objective is sent during the "cleanup".Do
> you have any advice on how to prevent the objective from switching
> following the completion of the MDA?  Is there some sort of default
> objective setting that we set accidentally? Thank you in advance!
>
> A bit about our system:
>
>   * Micromanager: 1.4.23
>

Source code of the Oughtafocus plugin (for 1.4.23) is here:
https://valelab4.ucsf.edu/svn/micromanager2/trunk/autofocus/OughtaFocus.java

Search for the variable "oldState".  It looks like the fullFocus method
sets that to the state of whatever is in your ChannelGroup. If you
happen to have set a channelgroup in which you have an objective, then
that could explain things.

I guess that the idea is to focus using a specific config-setting, and
to return the system after this was done.  Let me know if this makes
sense with what you observe.




Best,

Nico


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

_______________________________________________
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: Objective changing after MDA

Kevin Yamauchi
Thanks for the quick reply, Nico! I will verify that our core channelGroup doesn’t specify an objective. My suspicion is this is not the issue because the objective change only occurs after the acquisition ends and not at every position when oughtafocus is run. In the log file, the objective change occurs after the [AE] (acquisition engine) prints “cleanup”. Do you know where in the source code the post-acquisition “cleanup” occurs? Thanks again for all of your help!

Harris, we will definitely keep you updated as we troubleshoot and let you know if we figure anything out!


Thanks,
Kevin

On Friday, December 6, 2019, MORRISON Harris <[hidden email]> wrote:
Morning,

I had exactly the same issue this week though not every time. Plus the microscope itself Zeiss Observer Z1) was not communicating the change in objective i.e. the Lens group set in the Main window still showed the original lens for acquisition instead of the one after the change. 

I'll give your suggestion a try, thanks Nico.

H


Harris Morrison

Advanced Imaging Resource (AIR)

MRC Human Genetics Unit

Institute of Genetics and Molecular Medicine (IGMM)

Carrington Crescent,

University of Edinburgh

Crewe Road

EH4 2XU



From: Nico Stuurman <[hidden email]>
Sent: 06 December 2019 02:07
To: Micro-Manager General <[hidden email]>; Kevin Yamauchi <[hidden email]>
Subject: Re: [micro-manager-general] Objective changing after MDA
 
On 12/5/19 1:59 PM, Kevin Yamauchi wrote:
> e are experiencing an issue where at the end of a multidimensional
> acquisition (autofocus, z slices, multiple positions, multi-channel),
> the objective will switch to a different objective. In our tests, we
> seem to only be able to reproduce the behavior when we use the
> "Oughtafocus" autofocus plugin (i.e., when  we use other autofocus
> plugins, the objective does not switch at the end of an MDA). When I
> checked the log file (full log attached, snippet below), it appears
> that the command to switch objective is sent during the "cleanup".Do
> you have any advice on how to prevent the objective from switching
> following the completion of the MDA?  Is there some sort of default
> objective setting that we set accidentally? Thank you in advance!
>
> A bit about our system:
>
>   * Micromanager: 1.4.23
>

Source code of the Oughtafocus plugin (for 1.4.23) is here:
https://valelab4.ucsf.edu/svn/micromanager2/trunk/autofocus/OughtaFocus.java

Search for the variable "oldState".  It looks like the fullFocus method
sets that to the state of whatever is in your ChannelGroup. If you
happen to have set a channelgroup in which you have an objective, then
that could explain things.

I guess that the idea is to focus using a specific config-setting, and
to return the system after this was done.  Let me know if this makes
sense with what you observe.




Best,

Nico


_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.


_______________________________________________
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: Objective changing after MDA

Nico Stuurman-2
Hi Kevin,
> Thanks for the quick reply, Nico! I will verify that our core
> channelGroup doesn’t specify an objective. My suspicion is this is not
> the issue because the objective change only occurs after the
> acquisition ends and not at every position when oughtafocus is run. In
> the log file, the objective change occurs after the [AE] (acquisition
> engine) prints “cleanup”. Do you know where in the source code the
> post-acquisition “cleanup” occurs?

You are right.  What bugs me, is that you write that you only see this
when using the Oughtafocus method.

The cleanup procedure is in the acquisition engine (regretfully written
in Clojure).  Specifically, it is in

acqEngine/src/org/micromanager/acq_engine.clj

The method "cleanup" (on line 676) calls the method "return-config"
(line 524), which compares the current state to "init-system-state" and
sets the things that differ back to the init-system-state.  So, somehow,
the 10x objective is recorded in "init-system-state".  As far as I can
see, init-system-state is set on line 665, in the function
"prepare-state" (on line 641).  "prepare-state" is only called at the
beginning of the acquisition (i.e., in the function run-acquisition on
line 767. The initial state is read from the system (Core) cache.  So,
if for one reason or another the cache has incorrect information about
the objective, then it will return to that incorrect value.  You could
possible check if this is the case by pressing the "Refresh" button on
the main window before starting the acquisition.  This will force an
update of the cache.  You could test if this is the explanation, by
switching the objective after you press Refresh, running a test
acquisition, and see if the acquisition engine at the end switches to
the "old" objective.  If this is all correct, you could remedy the
problem by always pressing Refresh before running the acquisition
(annoying, but doable).

In the logs that you emailed, I do see that you switched from the 10x to
the 20x objective before running the acquisition.  I am not sure why
that switch would not register in the cache, but that seems the most
likely explanation for what you observe.


Hope this gets you somewhere!


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: Objective changing after MDA

Kevin Yamauchi
Hello Nico,

Thanks for the additional information! Your hypothesis totally jives with the testing we just did:
  • The channel group used by oughtafocus doesn't contain any objective settings. Given this and the fact that the objective switch is only observed at the end of the acquisition, I don't think that is the main issue.
  • We confirmed that the systemStateCache is not getting updated when we change the objective through the Micromanager GUI by printing the results of core.getSystemStateCache().
  • We confirmed that we manually updating the state of the microscope (core.setState()) fixes the problem (i.e., the microscope objective does not change at the end of the acquisition).
In light of this, we will try the "Refresh" button as you suggested and report back. Do you have any thoughts on why changing the objective would not update the system state cache? Is there a property we can add to the property group that would force an update when we change the objective?

Thanks again for your help!

On Fri, Dec 6, 2019 at 11:24 AM Nico Stuurman <[hidden email]> wrote:
Hi Kevin,
> Thanks for the quick reply, Nico! I will verify that our core
> channelGroup doesn’t specify an objective. My suspicion is this is not
> the issue because the objective change only occurs after the
> acquisition ends and not at every position when oughtafocus is run. In
> the log file, the objective change occurs after the [AE] (acquisition
> engine) prints “cleanup”. Do you know where in the source code the
> post-acquisition “cleanup” occurs?

You are right.  What bugs me, is that you write that you only see this
when using the Oughtafocus method.

The cleanup procedure is in the acquisition engine (regretfully written
in Clojure).  Specifically, it is in

acqEngine/src/org/micromanager/acq_engine.clj

The method "cleanup" (on line 676) calls the method "return-config"
(line 524), which compares the current state to "init-system-state" and
sets the things that differ back to the init-system-state.  So, somehow,
the 10x objective is recorded in "init-system-state".  As far as I can
see, init-system-state is set on line 665, in the function
"prepare-state" (on line 641).  "prepare-state" is only called at the
beginning of the acquisition (i.e., in the function run-acquisition on
line 767. The initial state is read from the system (Core) cache.  So,
if for one reason or another the cache has incorrect information about
the objective, then it will return to that incorrect value.  You could
possible check if this is the case by pressing the "Refresh" button on
the main window before starting the acquisition.  This will force an
update of the cache.  You could test if this is the explanation, by
switching the objective after you press Refresh, running a test
acquisition, and see if the acquisition engine at the end switches to
the "old" objective.  If this is all correct, you could remedy the
problem by always pressing Refresh before running the acquisition
(annoying, but doable).

In the logs that you emailed, I do see that you switched from the 10x to
the 20x objective before running the acquisition.  I am not sure why
that switch would not register in the cache, but that seems the most
likely explanation for what you observe.


Hope this gets you somewhere!


Best,


Nico


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


_______________________________________________
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: Objective changing after MDA

oftakofta
Hello Nico and the rest,

We have been having similar stochastic objective change issues for some time and we don't use Oughtafocus. I have just told users to restart MM and that has solved it, but fixing this issue has been on my "I'll look in to it" list for quite some time now, thanks for sharing!


/Jens Eriksson
Sellin Imaging Platform
Uppsala University 


On Fri, Dec 6, 2019 at 10:07 PM Kevin Yamauchi <[hidden email]> wrote:
Hello Nico,

Thanks for the additional information! Your hypothesis totally jives with the testing we just did:
  • The channel group used by oughtafocus doesn't contain any objective settings. Given this and the fact that the objective switch is only observed at the end of the acquisition, I don't think that is the main issue.
  • We confirmed that the systemStateCache is not getting updated when we change the objective through the Micromanager GUI by printing the results of core.getSystemStateCache().
  • We confirmed that we manually updating the state of the microscope (core.setState()) fixes the problem (i.e., the microscope objective does not change at the end of the acquisition).
In light of this, we will try the "Refresh" button as you suggested and report back. Do you have any thoughts on why changing the objective would not update the system state cache? Is there a property we can add to the property group that would force an update when we change the objective?

Thanks again for your help!

On Fri, Dec 6, 2019 at 11:24 AM Nico Stuurman <[hidden email]> wrote:
Hi Kevin,
> Thanks for the quick reply, Nico! I will verify that our core
> channelGroup doesn’t specify an objective. My suspicion is this is not
> the issue because the objective change only occurs after the
> acquisition ends and not at every position when oughtafocus is run. In
> the log file, the objective change occurs after the [AE] (acquisition
> engine) prints “cleanup”. Do you know where in the source code the
> post-acquisition “cleanup” occurs?

You are right.  What bugs me, is that you write that you only see this
when using the Oughtafocus method.

The cleanup procedure is in the acquisition engine (regretfully written
in Clojure).  Specifically, it is in

acqEngine/src/org/micromanager/acq_engine.clj

The method "cleanup" (on line 676) calls the method "return-config"
(line 524), which compares the current state to "init-system-state" and
sets the things that differ back to the init-system-state.  So, somehow,
the 10x objective is recorded in "init-system-state".  As far as I can
see, init-system-state is set on line 665, in the function
"prepare-state" (on line 641).  "prepare-state" is only called at the
beginning of the acquisition (i.e., in the function run-acquisition on
line 767. The initial state is read from the system (Core) cache.  So,
if for one reason or another the cache has incorrect information about
the objective, then it will return to that incorrect value.  You could
possible check if this is the case by pressing the "Refresh" button on
the main window before starting the acquisition.  This will force an
update of the cache.  You could test if this is the explanation, by
switching the objective after you press Refresh, running a test
acquisition, and see if the acquisition engine at the end switches to
the "old" objective.  If this is all correct, you could remedy the
problem by always pressing Refresh before running the acquisition
(annoying, but doable).

In the logs that you emailed, I do see that you switched from the 10x to
the 20x objective before running the acquisition.  I am not sure why
that switch would not register in the cache, but that seems the most
likely explanation for what you observe.


Hope this gets you somewhere!


Best,


Nico


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


--
Science is built up of facts, as a house is built of stones; but an accumulation of facts is no more a science than a heap of stones is a house.  /Henri Poincaré


_______________________________________________
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: Objective changing after MDA

Nico Stuurman-2
In reply to this post by Kevin Yamauchi
Hi Kevin,

>
> Thanks for the additional information! Your hypothesis totally jives
> with the testing we just did:
>
>   * The channel group used by oughtafocus doesn't contain any
>     objective settings. Given this and the fact that the objective
>     switch is only observed at the end of the acquisition, I don't
>     think that is the main issue.
>   * We confirmed that the systemStateCache is not getting updated when
>     we change the objective through the Micromanager GUI by printing
>     the results of core.getSystemStateCache().
>

Does the systemstateCache update when you change the objective directly
(i.e. using buttons on the microscope?

>   * We confirmed that we manually updating the state of the microscope
>     (core.setState()) fixes the problem (i.e., the microscope
>     objective does not change at the end of the acquisition).
>
> In light of this, we will try the "Refresh" button as you suggested
> and report back. Do you have any thoughts on why changing the
> objective would not update the system state cache? Is there a property
> we can add to the property group that would force an update when we
> change the objective?

That part is confusing, and has to do with the microscope providing
feedback about its state.  The code in the core that sets the
configuration (function CMMCore::applyConfiguration in
MMCore/MMCore.cpp) will "send" each property in the group to the
hardware, and then update the state cache, so after this happens, the
cache should be correct.  I suspect this has something to do with MM
listening to messages coming from the microscope, and updating its cache
based on these.  Nevertheless, everything I can glean from your logs
(the microscope sends $76033 2 3 11506529, where "2" is the new position
of the objective turret, and all looks like the DMI adapter code should
interpret this correctly.

Figuring this out why this does not work as expected will need working
with the hardware directly, and it is possible that the behavior in 1.4
and 2.0-gamma is different (would be interesting if you could check this).

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: Objective changing after MDA

Kevin Yamauchi
Hello Nico,

The "Refresh" button works! It updates the system state cache and fixes the objective changing issue. It's workable, but it would be nice if there was a way to do that automatically.

I tried changing objectives on the microscope and it does not change the value in the system cache.

I will try 2.0 gamma next week and let you know how it goes. Thanks and have a great weekend!

On Fri, Dec 6, 2019 at 2:22 PM Nico Stuurman <[hidden email]> wrote:
Hi Kevin,
>
> Thanks for the additional information! Your hypothesis totally jives
> with the testing we just did:
>
>   * The channel group used by oughtafocus doesn't contain any
>     objective settings. Given this and the fact that the objective
>     switch is only observed at the end of the acquisition, I don't
>     think that is the main issue.
>   * We confirmed that the systemStateCache is not getting updated when
>     we change the objective through the Micromanager GUI by printing
>     the results of core.getSystemStateCache().
>

Does the systemstateCache update when you change the objective directly
(i.e. using buttons on the microscope?

>   * We confirmed that we manually updating the state of the microscope
>     (core.setState()) fixes the problem (i.e., the microscope
>     objective does not change at the end of the acquisition).
>
> In light of this, we will try the "Refresh" button as you suggested
> and report back. Do you have any thoughts on why changing the
> objective would not update the system state cache? Is there a property
> we can add to the property group that would force an update when we
> change the objective?

That part is confusing, and has to do with the microscope providing
feedback about its state.  The code in the core that sets the
configuration (function CMMCore::applyConfiguration in
MMCore/MMCore.cpp) will "send" each property in the group to the
hardware, and then update the state cache, so after this happens, the
cache should be correct.  I suspect this has something to do with MM
listening to messages coming from the microscope, and updating its cache
based on these.  Nevertheless, everything I can glean from your logs
(the microscope sends $76033 2 3 11506529, where "2" is the new position
of the objective turret, and all looks like the DMI adapter code should
interpret this correctly.

Figuring this out why this does not work as expected will need working
with the hardware directly, and it is possible that the behavior in 1.4
and 2.0-gamma is different (would be interesting if you could check this).

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: Objective changing after MDA

BenjaminPelz

Hi Kevin and Nico,

 

This sounds very similar to an issue I had with the Oughtafocus plugin and it setting a different z-position to the one at the beginning of the MDA (http://micro-manager.3463995.n2.nabble.com/Potential-bug-in-OughtaFocus-code-td7588749.html).

 

If I remember correctly it had to do with, what you mentioned before, setting the system state to "oldState" which actually doesn’t correspond to the state at the beginning of the MDA. I think he updates the “oldState” when you manually use the autofocus function.

 

Best,

Benjamin

 

From: Kevin Yamauchi <[hidden email]>
Sent: Saturday, 7 December 2019 02:06
To: Nico Stuurman <[hidden email]>
Cc: Micro-Manager General <[hidden email]>
Subject: Re: [micro-manager-general] Objective changing after MDA

 

Hello Nico,

 

The "Refresh" button works! It updates the system state cache and fixes the objective changing issue. It's workable, but it would be nice if there was a way to do that automatically.

 

I tried changing objectives on the microscope and it does not change the value in the system cache.

 

I will try 2.0 gamma next week and let you know how it goes. Thanks and have a great weekend!

 

On Fri, Dec 6, 2019 at 2:22 PM Nico Stuurman <[hidden email]> wrote:

Hi Kevin,
>
> Thanks for the additional information! Your hypothesis totally jives
> with the testing we just did:
>
>   * The channel group used by oughtafocus doesn't contain any
>     objective settings. Given this and the fact that the objective
>     switch is only observed at the end of the acquisition, I don't
>     think that is the main issue.
>   * We confirmed that the systemStateCache is not getting updated when
>     we change the objective through the Micromanager GUI by printing
>     the results of core.getSystemStateCache().
>

Does the systemstateCache update when you change the objective directly
(i.e. using buttons on the microscope?

>   * We confirmed that we manually updating the state of the microscope
>     (core.setState()) fixes the problem (i.e., the microscope
>     objective does not change at the end of the acquisition).
>
> In light of this, we will try the "Refresh" button as you suggested
> and report back. Do you have any thoughts on why changing the
> objective would not update the system state cache? Is there a property
> we can add to the property group that would force an update when we
> change the objective?

That part is confusing, and has to do with the microscope providing
feedback about its state.  The code in the core that sets the
configuration (function CMMCore::applyConfiguration in
MMCore/MMCore.cpp) will "send" each property in the group to the
hardware, and then update the state cache, so after this happens, the
cache should be correct.  I suspect this has something to do with MM
listening to messages coming from the microscope, and updating its cache
based on these.  Nevertheless, everything I can glean from your logs
(the microscope sends $76033 2 3 11506529, where "2" is the new position
of the objective turret, and all looks like the DMI adapter code should
interpret this correctly.

Figuring this out why this does not work as expected will need working
with the hardware directly, and it is possible that the behavior in 1.4
and 2.0-gamma is different (would be interesting if you could check this).

Best,


Nico



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