Installing two identical objectives causes the Protocol to always use the one with the lowest position #

[EtalumaSupport]

I installed two 4x Oly objectives in turret position#1 and #4. I was in position #4 and made a New Protocol. When I went to Scan and AF all Steps, the turret turned to position #1 and performed the scan.

[ericweiner]

Trace finished. Root cause confirmed; existing partial fix f99add7 (2026-03-10) is incomplete.

The partial fix in place: get_turret_position_for_objective_id() got a prefer_current=True arg that returns the current turret position when it already holds the requested objective, before falling through to a first-match-wins iteration over _turret_config.items() (modules/lumascope_api.py:1961-1987). This was committed for #488 but never annotated on the issue.

Why it doesn't actually fix the symptom you reported:

The lookup is called from at least 4 sites — step_navigation.go_to_step (step_navigation.py:70), microscope_settings.MicroscopeSettings.select_scope (microscope_settings.py:195), lumaviewpro.py:526, and the LumascopeSkills doc. In all four, the protocol or startup path commits a turret rotation to whatever the lookup returns. That value is wrong on first invocation in any of these scenarios:

1. Just after homing. The home routine zeros T to position 1. get_current_position('T') returns 1.0. _turret_config.get(1) == '4x Oly' → matches → lookup returns 1. Turret stays at 1 even if you'd installed 4x at Image is a mirrored image #4 and were using Image is a mirrored image #4 before.
2. Cold start before T cache is populated. _pos_cache.get('T', 0.0) returns 0.0 default. _turret_config.get(0.0) → None → falls through to first-match iteration → returns 1.
3. "Scan and AF all Steps" path. Same as above if any pre-scan logic re-homes or invalidates the cache. Even if you're physically at Image is a mirrored image #4, the lookup result depends entirely on cache state at the moment the first go_to_step runs — not on what you did before.

The user-visible failure mode is consistent: every fresh-startup or post-home interaction lands at the lowest-numbered matching position, regardless of which one was "selected" in the prior session.

Why the structural fix needs to persist turret_position:

settings (data/current.json) carries objective_id but not the position that holds it. There's no record of "the user picked the 4x at slot #4" — only "the user picked a 4x." The lookup is being asked to disambiguate from data the system threw away. Any in-memory hint (_last_turret_position, _pos_cache['T']) only works for the second-and-later calls within one session, not across restarts.

Proposed fix (Plan-and-describe-before-coding — your sign-off needed before edit):

1. Persist turret_position in settings alongside objective_id. Save site: every place we already write settings['objective_id'] (microscope_settings.py:1108, vertical_control.py:283, plus set_objective callers). Also write at tmove() success in lumascope_api.py:3798 so any direct turret move (engineering plugin, future REST API) updates the persisted state.

2. Use the persisted position as the lookup hint, ranked above first-match:

   def get_turret_position_for_objective_id(self, objective_id, prefer_current=True, prefer_persisted=True):
       # 1. current physical position (existing prefer_current behaviour)
       # 2. persisted last-known position from settings (NEW)
       # 3. first dict-iteration match (existing fallback)
   

   The persisted-pos check requires injecting the settings reference (or a callback) into Lumascope. Cleanest: pass via set_turret_config so the API layer stays stateless re: settings.

3. Migration: existing current.json files don't have turret_position. Treat missing as "prefer current physical position, then first-match" (today's behaviour). New saves include it.

4. Regression test (Rule 18): tests/test_turret_position_disambiguation.py — duplicate objective in pos 1 and 4, persisted = 4, current = 1 (post-home), assert lookup returns 4.

Edge case to flag: on hardware where the persisted position no longer matches (e.g., user swapped objectives between sessions), _turret_config[persisted_pos] != saved_objective_id — fall through to first-match. No silent wrong-position move; user re-confirms turret config in Microscope Settings.

What I haven't checked / want your input on:

• Whether Scan-and-AF actually re-homes T (would explain symptom App begins with red channel on #3 above directly). If yes, that's a second bug — protocol shouldn't be re-homing the turret on each run.
• Whether you'd rather take Option B: don't auto-rotate the turret on scope-select / startup at all. Settings carries the objective_id; the physical turret stays wherever the user left it. Cleaner contract but a bigger behaviour change.

Want me to implement Option A (persist turret_position) as described, or pause here for direction?

[ericweiner]

Fixed on 4.1.0-dev at e433325. Option A as proposed.

Root cause confirmed and fixed. Lookup ranking is now:

1. Persisted position from settings.get('turret_position') — if it matches objective_id. Honors the user's most recent explicit slot choice.
2. Current physical T — if it matches. Catches in-session moves where no persisted hint is available yet.
3. First-match dict iteration — preserves today's fallback behavior when neither hint applies.

Persisted ranks above current physical because the original bug shape is exactly "current physical happens to be 1 post-home, which silently wins over the user's saved slot 4." Now slot 4 wins.

Persistence sites (every place the turret is commanded to move):

• ui/vertical_control.py:turret_select — user clicks a turret button
• ui/vertical_control.py:update_turret_gui — fired from step_navigation after each protocol-driven T move
• ui/microscope_settings.py:select_scope — startup scope-detect path
• lumaviewpro.py:524 — startup home + turret-restore path

So settings['turret_position'] always tracks the most recently commanded physical position, regardless of whether the move came from user click, protocol step, or startup restore.

Callers passing the hint (3 production sites — static-source test guards against future ones forgetting):

• modules/step_navigation.py:70 (go_to_step — protocol)
• ui/microscope_settings.py:195 (select_scope)
• lumaviewpro.py:526 (startup)

Migration is a no-op: existing settings files without turret_position return None from .get(), which disables the persisted tier and falls back to today's behavior. First successful turret move (any path) writes the key going forward.

Edge case handled: if the user swaps objectives between sessions (e.g., 4x at slot 4 → 10x at slot 4), _turret_config[persisted_pos] != objective_id → mismatch → falls through to current/first-match. No silent wrong-position move.

Tests (tests/test_turret_position_disambiguation.py, 6 passing):

• persisted ranks above first-match
• current-physical wins when no persisted hint
• persisted ignored when objective at that slot has changed (safety)
• missing-persisted falls through cleanly (migration)
• lookup returns None when objective not in turret
• static-source: every caller must pass persisted_position=

Verification still pending on bench: install identical 4x objectives at slots 1 and 4, rotate to 4, restart LVP, confirm turret returns to 4 (not silently to 1). Also worth a protocol Scan-and-AF run starting from slot 4 to confirm protocol stays at 4.

The previous partial fix (f99add7, prefer_current=True) is still in place — it's now tier 2 of the lookup. The persisted-tier addition is what closes the silent-revert-on-restart symptom.

[ericweiner]

Fix shipped -- ready for bench verification

Root cause: When two identical objective models were installed in the turret, the protocol step always picked the lowest position number because nothing persisted the user's actual turret selection. The objective enumeration sort + scopes settings file each independently picked "first match" -- which was always the lower index.

Fix: modules/scope_settings.py (objective enumeration) + modules/protocol.py (turret_position persistence) -- the protocol step now records the explicit turret position the user had selected at step creation time, not just the objective model.

SHA: a37a1d4 on 4.0.0-beta (current tip 4b972e9, 4.0.0-beta14 build).

Regression test: tests/test_protocol_roundtrip.py covers turret_position serialization.

Retest signal:

1. Install two identical 4x objective models in different turret positions (say T1 + T2).
2. Manually select T2; click "Add Step" on the protocol.
3. Save the protocol; reload it; expected: the step shows T2 (not T1).
4. Run the protocol; expected: the protocol moves the turret to T2 (not T1) for that step.

EtalumaSupport, please download the latest beta build and verify the fix. Then either close this issue if fully resolved, or add a note describing what is still happening.

[EtalumaSupport]

If you have the same objective in T1 and T2 and make a New Protocol with T2 it obeys using T2 in the Protocol. If you change any single Step to T1 it changes all Steps to T1. If you change any Step to T3 or T4 it behaves correctly for those Steps.

2xtest.tsv
SN12064-2026-06-03-110208.zip