Repository navigation
Wait for every camera of a sequence before reporting missing images - #1
Merged
Merged
Conversation
acquireImages gave up when the buffer was empty and the Core camera had stopped (isSequenceRunning() with no argument). With a sequence on two cameras, the other camera can still be delivering its last frame after the Core camera has finished; the engine then threw "Expected images did not arrive in circular buffer" and the frame arrived just after. Check isSequenceRunning(camera) for every camera in the sequence, before the buffer count (a camera inserts its last image before it reports that it stopped). Seen with LightSheetManager on two PVCAM Kinetix cameras: 2 of 2004 volumes failed this way in one overnight run, each time with one image left in the buffer and both cameras stopped. A camera that stays running and never delivers now makes the loop wait where it used to throw; the event's timeout or an abort ends it, as for one camera. TestMultiCameraSequenceEnd reproduces the error with a native-free fake core and checks that a frame that never arrives is still reported. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014XvXpWXe3X8gdDpsE66ocY
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fork-internal draft for the fix in scapecontrol's DEVIATIONS D-80, so the AcqEngJ test workflow runs on it. Upstream (
micro-manager/AcqEngJ) gets an issue and a PR only after a rig run with the patched jar confirms it (scapecontrolbench/README.md, "Confirming the AcqEngJ fix"). The issue text is drafted in scapecontrol'sdocs/upstream/acqengj-multi-camera-sequence-end.md.What happens:
Engine.acquireImagesgave up when the buffer was empty andisSequenceRunning()was false. Without an argument, that call asks only about the Core camera. In a hardware sequence on two cameras, the other camera can still be delivering its last frame after the Core camera has finished. The engine then threw "Expected images did not arrive in circular buffer", and the frame arrived just after.This was seen with LightSheetManager on two PVCAM Kinetix cameras: 2 of 2004 volumes in one overnight run, each time with one image left in the buffer and both cameras stopped.
Fix: check
isSequenceRunning(camera)for every camera of the sequence, before the buffer count. A camera inserts its last image before it reports that it stopped, so the order matters. Side effect: a camera that stays running and never delivers now makes the loop wait where it used to throw; the event's timeout (micro-manager#141) or an abort ends it, as it already does for a single camera.Test:
TestMultiCameraSequenceEndis native-free and runs onRecordingCMMCore.9f46e53it fails with the rig's exact error.mvn test: all 14 tests pass locally.Generated by Claude Code