-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Position plan timing resets for each position #187
Comments
I think the problem with integration in pymmcore-plus might be a bit deeper. For fast acquisitions on larger samples, this could still be a problem even if the counter would not reset. Maybe the timer in pymmcore-plus should actually reset for a new position after the position is set? Might be worth thinking about a little more. |
just to confirm, the goal here is to run a complete time lapse at a given position before moving on to the next position right? (I can definitely see how the current |
@wl-stepp, on the useq-schema side, what do you think the [MDAEvent(index=mappingproxy({'t': 0, 'p': 0}), min_start_time=0.0, x_pos=100.0, y_pos=100.0),
MDAEvent(index=mappingproxy({'t': 1, 'p': 0}), min_start_time=1.0, x_pos=100.0, y_pos=100.0),
MDAEvent(index=mappingproxy({'t': 0, 'p': 1}), min_start_time=1.0, x_pos=0.0, y_pos=0.0),
MDAEvent(index=mappingproxy({'t': 1, 'p': 1}), min_start_time=2.0, x_pos=0.0, y_pos=0.0)] That's slightly better, but would still be insufficient in terms of actually yielding the desired result. We could could also allow an event to "reset" t0: [MDAEvent(index=mappingproxy({'t': 0, 'p': 0}), min_start_time=0.0, x_pos=100.0, y_pos=100.0),
MDAEvent(index=mappingproxy({'t': 1, 'p': 0}), min_start_time=1.0, x_pos=100.0, y_pos=100.0),
MDAEvent(index=mappingproxy({'t': 0, 'p': 1}), min_start_time=0.0, x_pos=0.0, y_pos=0.0, reset_timer=True),
MDAEvent(index=mappingproxy({'t': 1, 'p': 1}), min_start_time=1.0, x_pos=0.0, y_pos=0.0)] other ideas? basically, how do you think this should look on the useq side, such that we can implement the proper behavior on the engine side? |
Yes. I think the underlying question might be who should know about some of the timing constraints here, right? I like the reset_timer idea, that way the acquisition engine can also decide when exactly to reset the timer. For a long setup it could reset the timer after it has moved to the new position etc. for example. The user then gives up tight timing from the last event before and the event with the reset_timer flag. I think that's a good option to have for many applications. Our adaptive acquisitions might want to have tight timing up to a trigger but then do something more time consuming and reset the timer with the last event. Yeah, sounds good to me... How that is reflected in the metadata might be interesting to discuss, but if you give up tight timing across these events you might not be so interested in offsets anyways... And how downstream things might think that the time in the engine is monotonically rising... should there be a timerResetEvent? |
as i think about it now, i'm imagining that
would that all work for you? While we're at it, can you foresee any future needs that this would not meet (such as additional timers, ids, etc...) |
Yeah, that sounds great. |
btw, support added in pymmcore-plus in pymmcore-plus/pymmcore-plus#383 |
Hey everyone, sorry to re-open this, but I came across something that goes wrong here. For subsequences at different positions, somehow all events have the reset_event_timer flag. Looking at the pull request I don't get why... from pymmcore_plus import CMMCorePlus
from useq import MDASequence
from useq import Position
mmc = CMMCorePlus()
mmc.loadSystemConfiguration()
seq = MDASequence(
stage_positions=[Position(x=0, y=0,
sequence=MDASequence(channels=["Cy5"],
time_plan={"interval": 1, "loops": 5})),
Position(x=1, y=1,
sequence=MDASequence(channels=["DAPI"],
time_plan={"interval": 1, "loops": 5}))]
)
mmc.run_mda(seq) Output:
The t index is not zero, so I don't get why they would get the flag... |
Is this something that might be handled by #192 ? @tlambert03 |
I will open a new issue for this, but it's very similar to #149
On useq-schema-0.4.7:
See how the min_start_time resets.
With this the first position runs fine, but the later ones will run at full speed.
The text was updated successfully, but these errors were encountered: