please update the 4 files about focus algorithm in...

I’ll trace the full Auto Light + Focus path, especially on_pushButton_clicked(), the continuous OBJ/CAM search, and the state checks that trigger “Finish the current automatic operation first.” Then I’ll update all four files and return complete replacements.

I found the false-positive gate: the button blocks on several persistent flags (m_chainActive, startup state, scan/focus flags), not just operations that are actually moving. I’m checking where each flag is cleared so the fix doesn’t accidentally allow the focus routine to collide with a real automatic run.

There’s a concrete stuck-state bug: the OBJ/CAM cell-search completion handler exists, but its call from the motor-reached callback is commented out. That can leave m_cellSearchActive true forever, which directly causes the message you’re seeing. I’m restoring that completion path (including status-only firmware handling) in addition to the focus changes.

The low-focus rescue is now structured as a separate pre-focus phase: below 5 it moves CAM by 1.0 mm and OBJ by 0.5 mm concurrently, samples after each step, and only hands back to the original OBJ→CAM routine after the score is above 10. The normal fast hunt is also changed to 500 steps/s with a longer search range and stronger protection against premature reversal.

The code pass is complete. I also verified brace balance and declaration/definition consistency. A full project compile isn’t possible from these four uploads alone because mainwindow.cpp depends on project headers such as analysisform.h, but the edited files are structurally consistent.

Updated the focus-button workflow. The original fast hunt was set to 1000 steps/s, and the cell-search motor completion callback was commented out—this could leave m_cellSearchActive stuck and cause the “Finish the current automatic operation first” message. (mainwindow.cpp) (mainwindow.cpp)

Changes made:

• Fast OBJ/CAM hunt: 1000 → 500 steps/s.
• Increased probe/search travel and prevented early reversal until the motor has moved farther past the detected peak.
• When initial focus is < 5:
  • CAM moves 1.0 mm per step.
  • OBJ moves 0.5 mm per step.
  • Both move together with synchronized speeds capped at 500.
  • It samples after every step.
  • It continues until focus is > 10, then restarts the normal OBJ → CAM focus algorithm.
  • It searches a full forward leg before reversing instead of changing direction too early.
• Restored onCellSearchMotorReached() for both normal motor-reached packets and idle-status packets.
• The busy popup now identifies which operation is actually blocking instead of only showing the generic message.
• Cancellation also stops the paired low-focus CAM/OBJ movement safely.
• autofocus.cpp and autofocus.h are included as full files; they required no functional motor-focus changes because this button’s OBJ/CAM state machine is implemented in MainWindow.

Full files:

[Download mainwindow.cpp]
Download mainwindow.h
Download autofocus.cpp
Download autofocus.h

Download all 4 files as ZIP

I also checked brace balance and the new method declarations/definitions. A complete compile cannot be run from these four files alone because project dependencies such as analysisform.h were not included.

I’ll simplify the button workflow around exactly those three rules: fix lighting so it does not drive the image to white, remove autofocus from zoom changes, and reduce focus to a simple low-focus rescue → OBJ hunt at 500 → CAM hunt at 500. I’ll edit the latest four files and return full replacements again.

I’ve reduced the focus logic rather than layering more states on it. The revised behavior will be: sample → if <5, move CAM+OBJ by 1 mm steps → once >5, search OBJ continuously at 500 → if OBJ cannot reach the good-focus threshold, search CAM at 500; there is no 150-speed refinement pass in this button path.

One important side effect showed up while removing zoom autofocus: the startup sequence previously used “autofocus finished” as the signal that zoom was done. I’m changing that handoff so startup continues immediately after the zoom motor finishes, without starting autofocus; otherwise startup would stay stuck in its focusing state.

The simplified behavior is in place now. I’m doing the final consistency pass: checking that no old 150-speed/probe states are still referenced, that zoom completion advances startup without autofocus, and that the lighting cap/white-frame penalties are applied in both the incremental and synchronous lighting APIs.

Updated all 4 files with the simpler rules you requested.

• Lighting: much more conservative now. LED is capped at 160 (128 on retry), white/clipped frames are heavily rejected, target brightness is lower, and the lighting ROI uses the central 60% of the image.
• Zoom: changing zoom does not start autofocus anymore. Startup also continues after zoom without waiting for autofocus.
• Focus < 5: CAM +1 mm and OBJ +1 mm, both at 500, step-by-step until focus becomes > 5.
• Focus > 5: OBJ searches at 500. It tries both directions if needed. If OBJ cannot reach the good-focus target (90), CAM searches at 500.
• Removed the 150-speed refinement, direction probes, and extra verify stages from this button focus path.

Full updated files:

mainwindow.cpp
mainwindow.h
autofocus.cpp
autofocus.h

Download all 4 updated files as ZIP

I also checked the modified files for unmatched braces, missing focus constants, stale probe/150-speed references, and old zoom-autofocus hooks. A full Qt project compile still requires the rest of your project headers/libraries.

I’ll make these as targeted changes, not another rewrite: lighting will only scan exposure −6/−7/−8 + ESP32 LED 0–255, with longer settling/sampling; OBJ motion will allow live lighting correction; and the focus watcher will react to every incoming focus score while OBJ/CAM is moving, stop immediately when a strong peak is seen, and remember/revisit the best live position so it does not drive past it.

The main cause of missed focus is clear in the current watcher: it smooths the score and requires repeated high readings before stopping, then it can finish at the stopped/overshot position instead of returning to the best position seen while moving. I’m changing that so one strong live score is enough to command a stop, and after any peak-triggered stop the motor returns to the recorded best live position and verifies it while stationary.

The lighting path is now restricted exactly as requested: exposure only −6/−7/−8, LED full 0–255, with 120 ms settling, frame discards, and 5 measured frames per setting. I also removed the Auto Light + Focus routine’s white-balance toggling, so that lighting stage no longer changes extra camera controls.

I’m also covering the case where CAM and OBJ are moving together in the <5 rescue. Previously those live scores were effectively ignored until the full 1 mm move finished. Now, if focus rises above 5 during that paired move, both motors are stopped immediately, their real stopped positions are read, and the score is rechecked before continuing.

The live watcher now covers all three motion cases: normal OBJ hunt, normal CAM hunt, and the paired CAM+OBJ low-focus rescue. It also keeps watching during the corrective “return to best” move, so a better score found on that return is not ignored.

Updated the four full files with the critical changes.

The new behavior is:

• Lighting only changes two things: camera exposure is strictly -6 / -7 / -8, and ESP32 LED searches the full 0–255 range. It no longer toggles white balance or other camera settings.
• Lighting evaluation is slower and more stable: 120 ms settle, 2 discarded frames, then 5 measured frames per setting. Very bright/near-white frames are explicitly rejected.
• While OBJ is moving, lighting can still improve live. It makes small LED adjustments and only changes exposure within -6/-7/-8; it does not stop OBJ to run another full lighting scan.
• The focus watcher now reads every raw focus score. It no longer requires the smoothed score to catch up before recognizing a good focus.
• A single 90+ live focus score immediately sends stop_motors.
• After stopping, it records where that best score happened, moves back to that exact best position, settles, and verifies the score there. This fixes the problem where the motor stopped after already passing the sharp point.
• The watcher remains active during that return-to-best movement too.
• During the <5 rescue, while CAM + OBJ move together, every focus score is watched. As soon as focus becomes >5, both motors are stopped immediately rather than completing the remaining 1 mm and potentially losing focus.
• Normal OBJ and CAM search remains 500 speed.
• Zoom autofocus remains disabled as in the previous update; autofocus is still initiated from the Auto Light + Focus button.

Full replacement files:

Download mainwindow.cpp
Download mainwindow.h
Download autofocus.cpp
Download autofocus.h

Download all 4 files as ZIP

I also ran structural checks on all four files for balanced braces/parentheses and verified the required exposure, LED, live-lighting, immediate-stop, low-focus watcher, and return-to-best code paths are present. A complete Qt compile still requires the rest of your project dependencies.

I’ll keep the current watcher improvements and only tune two things: make the lighting target slightly brighter without pushing it toward white, and replace the <5 rescue with a smarter two-axis move_t search that tries both directions for CAM and OBJ instead of repeatedly stepping one way.

The current <5 rescue is still using two absolute MOVE_S 1 mm targets, which is why it can exhaust its step limit without finding the useful direction. I’m replacing only that part with a bounded move_t sweep: both axes run at 500 together, the watcher checks every score, and it tries the four direction combinations (+,+), (-,-), (+,-), (-,+) with an immediate stop as soon as focus exceeds 5.

The low-focus rescue is now much more robust: it no longer has a fixed “forward then reverse step count.” Each short move_t leg runs both axes together and the same live watcher that protects the normal focus search can stop them immediately at >5; if the stop overshoots and the settled score falls below 5, the next leg automatically reverses toward the region where the good score was seen.

The lighting adjustment is deliberately small: the preferred median moved from 92 → 100, and the live “too dark” thresholds moved up slightly, while the clipped/too-bright protection remains unchanged. So it should choose a somewhat brighter image without returning to the washed-out white behavior.

Updated with the two changes you asked for.

For lighting, I only made it slightly brighter:

• target median: 92 → 100
• live dark threshold slightly higher
• exposure remains only -6 / -7 / -8
• LED remains 0–255
• white/clipped protection is still active

For focus < 5, I removed the old 1 mm MOVE_S stepping. It now uses move_t at speed 500 for both CAM and OBJ together and watches every focus score continuously.

The rescue tries these direction combinations:

• OBJ + + CAM +
• OBJ - + CAM -
• OBJ + + CAM -
• OBJ - + CAM +

As soon as any live focus score becomes > 5, it sends stop_motors immediately, reads the real CAM/OBJ positions, settles, verifies the score, then starts the normal OBJ 500-speed focus search.

If it briefly sees >5 but stopping overshoots and the settled score becomes <5, it automatically reverses toward the direction where the good score was detected instead of continuing farther away.

Full updated files:

Download mainwindow.cpp
Download mainwindow.h
Download autofocus.cpp
Download autofocus.h

Download all 4 files as ZIP

I also checked the edited files for balanced C++ braces/parentheses, stale old low-focus variables, and declaration/definition mismatches.

I’ll keep the current structure and tune only the rescue/lighting behavior: the <5 mode will get a much larger retry budget, remember the best score/positions across attempts, revisit promising regions instead of declaring failure early, and only give up after exhausting several full direction cycles. I’ll also brighten lighting another small step without weakening the anti-white protection.

I found why it can end with a best score around 4: the rescue currently allows only two complete direction passes, and the longer pass is still relatively short for OBJ because OBJ has far more steps/mm than CAM. I’m extending it to several progressively longer passes and adding a “promising region” revisit: if it saw a better sub-5 score earlier in a leg, the next attempt deliberately steers back toward that recorded CAM/OBJ region before continuing the remaining direction combinations.

The “almost there” case now gets special treatment: if the rescue reaches 4.0 or better but still not above 5, it automatically earns two extra full four-direction passes. Normal low-focus rescue now gets six passes instead of two, later passes run longer, and up to ten short revisits can steer both axes back toward the best sub-5 region seen so far instead of abandoning it.

Updated it to give the low-focus rescue much more persistence and make the image a little brighter.

The <5 rescue now gets 6 full four-direction passes instead of 2, with progressively longer move_t legs. If it reaches 4.0 or higher, it automatically gets 2 additional full passes because that means it is close to the useful focus region. It can also perform up to 10 short revisits toward the best CAM/OBJ position where it previously saw an improved sub-5 score, rather than continuing away and then quitting.

Lighting is only slightly brighter: the preferred median changed from 100 → 108, and the live lighting thresholds were raised a little. The strong white/clipping protection remains unchanged, and exposure is still restricted to -6/-7/-8.

Full updated files:

Download mainwindow.cpp
Download mainwindow.h
Download autofocus.cpp
Download autofocus.h

Download all 4 updated files as ZIP

I’ll use your measured x2/x3/x4 focus positions as the new starting model instead of blindly searching from wherever the motors happen to be. The key change will be: autofocus runs only from the Auto Light + Focus button; when pressed, it first moves one axis at a time toward a zoom-predicted focus neighborhood, then uses OBJ very finely because your data shows 0.1 mm on OBJ can change focus a lot.

Your three measurements show a useful optical pattern: CAM is the coarse zoom/focus axis (it changes a lot between x2→x4), while OBJ is the sensitive fine axis (its position changes much less, so 0.1 mm matters). I’m using the x2/x3/x4 points as piecewise calibration anchors: zoom moves go near those measured positions without running autofocus, and the button focus routine searches CAM/OBJ one at a time around that calibrated neighborhood.

I’ve also changed the decision order based on your measurements: CAM first, OBJ second. CAM makes the large coarse correction for zoom; OBJ is left last for the sensitive correction. The live watcher on OBJ is now much tighter—its peak/drop logic reacts within well under 0.1 mm instead of waiting through the old larger travel window.

The automatic triggers are removed now: stage/SLD/CAR movement no longer arms autofocus, auto-capture no longer starts/waits for autofocus, cell-search no longer falls into autofocus, and zoom completion only completes zoom. Manual focus controls remain available, but no motor movement starts them by itself.

Updated the focus logic around your measured x2/x3/x4 positions.

The important behavior now is:

• No automatic autofocus from movement. Moving SLD, CAR, OBJ, CAM, changing zoom, startup positioning, auto-capture, or cell-search will not start autofocus. Autofocus starts only from an explicit focus-button action.
• CAM and OBJ are never moved together in the Auto Light + Focus algorithm.
• Your measured positions are now calibration anchors:
  • x2 → CAM 29.726, OBJ 16.913
  • x3 → CAM 41.386, OBJ 17.158
  • x4 → CAM 77.671, OBJ 17.977
• For zoom values between them, the code interpolates between the measured points. It does not guess/extrapolate this model outside x2–x4.
• Zoom now moves CAM first, OBJ second. CAM is treated as the coarse axis; OBJ is treated as the sensitive fine axis.
• When the focus button is pressed, it uses the zoom calibration first to get near the expected focus position, again one motor at a time.
• Normal focus then searches OBJ first at 500. OBJ search is intentionally narrow because your measurements indicate that even 0.1 mm can make a large focus change.
• The OBJ watcher now reacts much faster: it can recognize a passed peak after roughly 0.04–0.06 mm of relevant movement rather than allowing a much larger overshoot.
• If OBJ cannot find the preferred focus, CAM gets a wider 500-speed search.
• If focus is initially <5, the rescue is now sequential:
  • CAM searches + and − alone.
  • If that cannot get above 5, OBJ searches + and − alone.
  • It allows up to 3 complete CAM/OBJ recovery cycles rather than stopping after one try.
  • The moment a moving axis gets above 5, its exact live region is recorded, the motor stops, returns to the best observed point, verifies it, and then resumes normal OBJ-first focusing.
• The live watcher continues checking every incoming focus score during movement and during the return-to-best movement.

Full updated files:

[Download mainwindow.cpp]

Download mainwindow.h

Download autofocus.cpp

Download autofocus.h

Download all 4 files as ZIP

I also checked all four files for balanced braces/parentheses and verified there are no remaining automatic calls to startAutoFocus() from zoom, stage movement, startup, cell-search, or auto-capture.