Quantcast

MM architecture and asynchronous communication

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

MM architecture and asynchronous communication

Gryphon
Hello,

I do not fully understand MM architecture and internal ideology, so I'd like to ask if asynchronous communication with devices is needed and if yes, what is better way to implement it.
As far as I get it, all command are send in sequence, not in parallel, i.e. if we need to close two shutters, we cannot send "close" command to the second shutter before we receive "done" from the first. It seems convenient to have nob-blocking communication, but I cannot get what to do with indication and error handling. Let us suppose, I send a command that will take significant time, ~3 sec. What should be written in Property browser during command evaluation: previous value, or final value, or "unknown", or "Hic sunt dracones"? What should we do if we get an error when one of parallel operations failed, is there a common way to rollback? When preparing a pipeline in MDA, how to notice MM which operations can be run in parallel and which are strictly sequential?

Best,
Sergey
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MM architecture and asynchronous communication

Mark Tsuchida-3
Hi Sergey,

On Fri, Feb 10, 2017 at 7:32 AM, Gryphon <[hidden email]> wrote:
I do not fully understand MM architecture and internal ideology, so I'd like
to ask if asynchronous communication with devices is needed and if yes, what
is better way to implement it.
As far as I get it, all command are send in sequence, not in parallel, i.e.
if we need to close two shutters, we cannot send "close" command to the
second shutter before we receive "done" from the first. It seems convenient
to have nob-blocking communication, but I cannot get what to do with
indication and error handling. Let us suppose, I send a command that will
take significant time, ~3 sec. What should be written in Property browser
during command evaluation: previous value, or final value, or "unknown", or
"Hic sunt dracones"? What should we do if we get an error when one of
parallel operations failed, is there a common way to rollback? When
preparing a pipeline in MDA, how to notice MM which operations can be run in
parallel and which are strictly sequential?

All good questions, and the architecture is in some ways a work in progress. I think about these issues a lot myself.

Early on, MMCore was conceived as a single-threaded system, but with some asynchronous capabilities. Later it was made thread-safe for most operations.

Typically, sending a command to a device should work like this:

1. Application calls setProperty(...) (for example)

This will synchronously call into the device adapter module, which will send the command. If the command is time-consuming, the device adapter is encouraged to (but may not) return before the motion (or whatever) completes, putting the device in the "busy" state.

2. Application calls waitForDevice(...)

This will cause MMCore to poll the device's "busy" state until either the device becomes non-busy or the Core timeout has elapsed.

Most, but not all, slow movements (such as motorized stages or turrets) work this way. So the intended way this system was to be used was (still is, when sufficient) to send a bunch of commands and then call waitForSystem(...) (or other waitFor* functions).

This is not as fast as it could be, because typically setProperty() blocks while a round-trip communication to the device takes place. To do that part in parallel, the only way is to run each command in a separate thread, and MDA does exactly that.

This system also has a number of deficiencies that any concurrency expert would point out, including the fact that there is no way to monitor the completion/failure/cancellation of any _particular_ operation (even if the device itself has that capability, which is frequently not the case). But this is what we have.

One additional note on parallelism is that even if commands are send from separate threads, commands to the same device adapter module only get executed synchronously. This is because MMCore synchronizes access to each device adapter and is a result of retrofitting thread safety.

Also, sequence acquisitions from cameras work in a completely different way and were always fully asynchronous.

How can we improve this? Given that a complete replacement of the concurrency requirements for the device interface is not practical, I think there are two things that we can do:

1. Provide a programming interface that makes it easier to call devices in a nonblocking fashion. I have started implementing this in the Java layer (although the project has been on hold for quite a while). It will use all the modern concurrency facilities in Java (ExecutorService, etc.), and the nonblocking command methods will return Future objects. The system will proactively poll the "busy" state of devices when otherwise idle, so that explicit calls to waitFor* are no longer necessary.

Once this system is available, it should in fact be possible to make the Device Property Browser show "Busy" for values that are currently being changed.

2. We should probably make it possible for device adapters to accept certain commands in parallel. However, designing a backward-compatible interface for this is fairly complicated, and at this point this is just an idea.

Hope this answers most of your questions.

Best,
Mark

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MM architecture and asynchronous communication

Gryphon
Thank you, Mark,
Some more questions:
1. Is integrating concurrency and parallelism somehow planned, or I just got a new hobby?
2. Am I wrong saying that it is not necessary at the moment to make device adapters support async communication with corresponding device?
3. What should I do if at specific conditions my stage will not fit to core timeout (5s)?

Guys from MCL managed to make MicroDrive respond to "Stop" command to somehow interrupt movement. I have no idea how since the communication is based on closed-source library and Jungo driver. Is it reasonable to contact them?

Best,
Sergey
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MM architecture and asynchronous communication

Mark Tsuchida-3
Hi Sergey,

On Fri, Feb 10, 2017 at 3:36 PM, Gryphon <[hidden email]> wrote:
Some more questions:
1. Is integrating concurrency and parallelism somehow planned, or I just got
a new hobby?

Yes, I have some code for the core part of this. It is not in a usable state yet but I'm happy to share it after a bit of clean-up.
 
2. Am I wrong saying that it is not necessary at the moment to make device
adapters support async communication with corresponding device?

This really depends on the device's serial protocol or API. For most simple serial devices, the protocol is synchronous and you get the completion of motion by polling. Some more advanced devices (e.g. microscope stands), the protocol or SDK supports asynchronous notifications, and our device adapters typically have an asynchronous implementation.
 
3. What should I do if at specific conditions my stage will not fit to core
timeout (5s)?

You will need to increase the Core-Timeout property.

One thing we could improve here is to add a cancelable waitForDevice(), which may be more useful than a timeout in some scenarios.
 
Guys from MCL managed to make MicroDrive respond to "Stop" command to
somehow interrupt movement. I have no idea how since the communication is
based on closed-source library and Jungo driver. Is it reasonable to contact
them?

It's up to you, of course. I also don't know how it works for MCL MicroDrive, but a typical way a serial protocol for a stage works is that there are commands for "start move to (position)", "check if moving", and "halt", each of which get a reply within milliseconds or tens of milliseconds.

Best,
Mark

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general
Loading...