Unable to access mmc.getCurrentConfig()

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

Unable to access mmc.getCurrentConfig()

Bryant
Hi Micro-manager community,

I have a plugin that cares about the current state of the system.  It occasionally probes the state using calls to the core, which works fine when running MDA.

The problem is when a user runs his own script via Beanshell.  Suddenly, all of the updates to the core and hardware are not recognized by my plugin's instance of MMC.

For example:
within beanshell
// correctly sets the configuration
mmc.setConfig("config_group", "config_preset_state")
mmc.waitForConfig("config_group", "config_preset_state")

// correctly returns the configuration state
mmc.getCurrentConfig("config_group")

But if I call this from plugin after the first two lines are written in beanshell
mmc.getCurrentConfig("config_group")
will return null

I can make other calls to mmc:
mmc.getAvailableConfigGroups().get(i)
correctly returns the ith config group

And if my plugin mimics the beanshell, all is fine
// from plugin, is ok!
mmc.setConfig("config_group", "config_preset_state")
mmc.waitForConfig("config_group", "config_preset_state")
// correctly returns the configuration state
mmc.getCurrentConfig("config_group")

This is the case if the plugin .jar is located in the plugins/Micro-Manager or the mmplugins folder.

So for whatever reason, updates to mmc via Beanshell are opaque to outside observers?

Thanks

Bryant






_______________________________________________
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: Unable to access mmc.getCurrentConfig()

Stuurman, Nico
Hi Bryant,

> I have a plugin that cares about the current state of the system.  It
> occasionally probes the state using calls to the core, which works
> fine when running MDA.
>
> The problem is when a user runs his own script via Beanshell. 
> Suddenly, all of the updates to the core and hardware are not
> recognized by my plugin's instance of MMC.
>
> For example:
> *within beanshell*
> // correctly sets the configuration
> mmc.setConfig("config_group", "config_preset_state")
> mmc.waitForConfig("config_group", "config_preset_state")
>
> // correctly returns the configuration state
> mmc.getCurrentConfig("config_group")
>
> *But if I call this from plugin **after the first two lines are
> written in beanshell*
> mmc.getCurrentConfig("config_group")
> *will return null*
> *
> *
> *I can make other calls to mmc:*
> mmc.getAvailableConfigGroups().get(i)
> *correctly returns the ith config group*
> *
> *
> *And if my plugin mimics the beanshell, all is fine*
> // from plugin, is ok!
> mmc.setConfig("config_group", "config_preset_state")
> mmc.waitForConfig("config_group", "config_preset_state")
> // correctly returns the configuration state
> mmc.getCurrentConfig("config_group")
> *
> *
> This is the case if the plugin .jar is located in the
> plugins/Micro-Manager or the mmplugins folder.
>
> So for whatever reason, updates to mmc via Beanshell are opaque to
> outside observers?

That is so weird!  Regretfully, it is also a bit complicated to
reproduce (I'll have to create a plugin - or modify one - for this
specific purpose).  A simple experiment: load the demo-config, run
"mmc.setConfig("Channel", "FITC");" in the Beanshell panel, and then
press refresh in the main GUI window show that the main window does get
the correct information.

Instead of polling, you could try subscribing to the
org.micromanager.events.ConfigroupChangedEvent (subscribe using
mm.events), although I am not sure that will always fire.  Also do note
that getCurrentConfig is an expensive function, it will force MM to
query all the attached hardware that is part of the configgroup.  You
could try getCurrentConfigFromCache (but doubt that will solve the
current problem).

It is possible that something in the hardware changes between setting it
in the Beanshell script and polling in your plugin.  If no config
matches, then getCurrentConfig will return an empty string.  You could
check this possibility by reading out all the properties that make up
the config yourself in the plugin.

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: Unable to access mmc.getCurrentConfig()

Bryant
HI Nico

That is so weird!  Regretfully, it is also a bit complicated to 
reproduce (I'll have to create a plugin - or modify one - for this 
specific purpose).  A simple experiment: load the demo-config, run 
"mmc.setConfig("Channel", "FITC");" in the Beanshell panel, and then 
press refresh in the main GUI window show that the main window does get 
the correct information.

This approach seems to work fine.  I tried another experiment:  forget the plugin. If I run the beanshell script and let it finish (or terminate it early), it resets the "Channel" to null.  Refreshing the GUI will show no entry in the config group's preset.  Does completion or termination of a beanshell script reset or clear some states?

Instead of polling, you could try subscribing to the 
org.micromanager.events.ConfigroupChangedEvent (subscribe using 
mm.events), although I am not sure that will always fire.  Also do note 
that getCurrentConfig is an expensive function, it will force MM to 
query all the attached hardware that is part of the configgroup.  You 
could try getCurrentConfigFromCache (but doubt that will solve the 
current problem).

Indeed this is what I do.  When the event fires, I query the system to learn the channel name.  First I tried using event.getDatastore().getSummaryMetaData(). , but this returned null and lead me to believe "getSummaryMetaData" was faulty.  So I tried the "getCurrentConfig" approach instead ... 

The original post is the current technical problem I have.  But really, the question i'm asking is "how do I query the changroup's channel name in a way that works for either MDA or beanshell acquisitions?"

On Fri, May 24, 2019 at 6:04 PM Stuurman, Nico <[hidden email]> wrote:
Hi Bryant,

> I have a plugin that cares about the current state of the system.  It
> occasionally probes the state using calls to the core, which works
> fine when running MDA.
>
> The problem is when a user runs his own script via Beanshell. 
> Suddenly, all of the updates to the core and hardware are not
> recognized by my plugin's instance of MMC.
>
> For example:
> *within beanshell*
> // correctly sets the configuration
> mmc.setConfig("config_group", "config_preset_state")
> mmc.waitForConfig("config_group", "config_preset_state")
>
> // correctly returns the configuration state
> mmc.getCurrentConfig("config_group")
>
> *But if I call this from plugin **after the first two lines are
> written in beanshell*
> mmc.getCurrentConfig("config_group")
> *will return null*
> *
> *
> *I can make other calls to mmc:*
> mmc.getAvailableConfigGroups().get(i)
> *correctly returns the ith config group*
> *
> *
> *And if my plugin mimics the beanshell, all is fine*
> // from plugin, is ok!
> mmc.setConfig("config_group", "config_preset_state")
> mmc.waitForConfig("config_group", "config_preset_state")
> // correctly returns the configuration state
> mmc.getCurrentConfig("config_group")
> *
> *
> This is the case if the plugin .jar is located in the
> plugins/Micro-Manager or the mmplugins folder.
>
> So for whatever reason, updates to mmc via Beanshell are opaque to
> outside observers?

That is so weird!  Regretfully, it is also a bit complicated to
reproduce (I'll have to create a plugin - or modify one - for this
specific purpose).  A simple experiment: load the demo-config, run
"mmc.setConfig("Channel", "FITC");" in the Beanshell panel, and then
press refresh in the main GUI window show that the main window does get
the correct information.

Instead of polling, you could try subscribing to the
org.micromanager.events.ConfigroupChangedEvent (subscribe using
mm.events), although I am not sure that will always fire.  Also do note
that getCurrentConfig is an expensive function, it will force MM to
query all the attached hardware that is part of the configgroup.  You
could try getCurrentConfigFromCache (but doubt that will solve the
current problem).

It is possible that something in the hardware changes between setting it
in the Beanshell script and polling in your plugin.  If no config
matches, then getCurrentConfig will return an empty string.  You could
check this possibility by reading out all the properties that make up
the config yourself in the plugin.

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: Unable to access mmc.getCurrentConfig()

Stuurman, Nico


On 5/25/2019 9:24 AM, Bryant Chhun wrote:
That is so weird!  Regretfully, it is also a bit complicated to 
reproduce (I'll have to create a plugin - or modify one - for this 
specific purpose).  A simple experiment: load the demo-config, run 
"mmc.setConfig("Channel", "FITC");" in the Beanshell panel, and then 
press refresh in the main GUI window show that the main window does get 
the correct information.

This approach seems to work fine.  I tried another experiment:  forget the plugin. If I run the beanshell script and let it finish (or terminate it early), it resets the "Channel" to null.  Refreshing the GUI will show no entry in the config group's preset.  Does completion or termination of a beanshell script reset or clear some states?

I am not sure that I understand what works for you and what does not work.  I suspect that you have something in your channel group that changes state after you set the channel.  Try the same thing with the demo configuration.  When I do so, the Channel does not reset to null.  Also, with your microscope configuration, try setting the channel group, then press the Refresh button.  My prediction is that the channel will be set to null. 

You may have something in your channel group that changes its value (slightly) after setting it, resulting in the channel no longer matching.  When you query immediately after setting, it still is at the correct value, any delay, and it is no longer correct. 

It always helps to experiment with the demo configuration to figure out if something is related to your specific configuration and/or hardware.  If you can recreate an example with the demo configuration that I can reproduce, then we will have something to look at.

Instead of polling, you could try subscribing to the 
org.micromanager.events.ConfigroupChangedEvent (subscribe using 
mm.events), although I am not sure that will always fire.  Also do note 
that getCurrentConfig is an expensive function, it will force MM to 
query all the attached hardware that is part of the configgroup.  You 
could try getCurrentConfigFromCache (but doubt that will solve the 
current problem).

Indeed this is what I do.  When the event fires, I query the system to learn the channel name. 

Why?  The ConfigGroupChangedEvent has that information:
event.getGroupName();
event.getNewConfig();


Best,


Nico




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