[DETECTION]: Actual Filament Measurement reseting

[Natclanwy]

Detection Issue Type

Other Detection Issue

Problem Description

The actual filament measurement is reseting in the middle of a print. I have observed this at least 3 times over the last couple of days since updating to v0.8.0-alpha

Steps to Reproduce

1. Restarted the SFS
2. Started a print
3. Regularly monitoring the WebUI and recording logs.

ESP32 Board

ESP32-S3

Firmware Version

v0.8.0-alpha

Relevant Configuration

All settings are at the default values

Logs

2025-12-26 09:50:39 Debug: sdcp_exp=7108.96mm cumul_sns=7051.08mm pulses=2308 | win_exp=26.89 win_sns=24.44 deficit=2.45 | jam=0 hard=0.00 soft=0.00 pass=1.01 grace=0 heap=166028
2025-12-26 09:50:40 Debug: sdcp_exp=7108.96mm cumul_sns=7051.08mm pulses=2308 | win_exp=24.72 win_sns=24.44 deficit=0.28 | jam=0 hard=0.00 soft=0.00 pass=0.91 grace=0 heap=166056
2025-12-26 09:50:40 Debug: sdcp_exp=7108.96mm cumul_sns=7054.14mm pulses=2309 | win_exp=22.80 win_sns=27.50 deficit=0.00 | jam=0 hard=0.00 soft=0.00 pass=1.11 grace=0 heap=165640
2025-12-26 09:50:40 Debug: sdcp_exp=7110.98mm cumul_sns=7054.14mm pulses=2309 | win_exp=24.82 win_sns=27.50 deficit=0.00 | jam=0 hard=0.00 soft=0.00 pass=1.11 grace=0 heap=166028
2025-12-26 09:50:40 Debug: sdcp_exp=7110.98mm cumul_sns=7054.14mm pulses=2309 | win_exp=24.82 win_sns=27.50 deficit=0.00 | jam=0 hard=0.00 soft=0.00 pass=1.11 grace=0 heap=167204
2025-12-26 09:50:40 Debug: sdcp_exp=7110.98mm cumul_sns=7054.14mm pulses=2309 | win_exp=24.82 win_sns=24.44 deficit=0.38 | jam=0 hard=0.00 soft=0.00 pass=1.11 grace=0 heap=165836
2025-12-26 09:50:40 Debug: sdcp_exp=7112.99mm cumul_sns=7054.14mm pulses=2309 | win_exp=24.45 win_sns=24.44 deficit=0.01 | jam=0 hard=0.00 soft=0.00 pass=0.98 grace=0 heap=165820
2025-12-26 09:50:41 Debug: sdcp_exp=7112.99mm cumul_sns=7057.19mm pulses=2310 | win_exp=24.45 win_sns=27.50 deficit=0.00 | jam=0 hard=0.00 soft=0.00 pass=1.00 grace=0 heap=164044
2025-12-26 09:50:41 Debug: sdcp_exp=7112.99mm cumul_sns=7057.19mm pulses=2310 | win_exp=22.06 win_sns=24.44 deficit=0.00 | jam=0 hard=0.00 soft=0.00 pass=1.12 grace=0 heap=165848
2025-12-26 09:50:41 Debug: sdcp_exp=7112.99mm cumul_sns=7057.19mm pulses=2310 | win_exp=22.06 win_sns=24.44 deficit=0.00 | jam=0 hard=0.00 soft=0.00 pass=1.12 grace=0 heap=167204
2025-12-26 09:50:41 Debug: sdcp_exp=7115.35mm cumul_sns=7057.19mm pulses=2310 | win_exp=22.04 win_sns=24.44 deficit=0.00 | jam=0 hard=0.00 soft=0.00 pass=1.11 grace=0 heap=165612
2025-12-26 09:50:41 Debug: sdcp_exp=7117.62mm cumul_sns=7060.25mm pulses=2311 | win_exp=24.30 win_sns=24.44 deficit=0.00 | jam=0 hard=0.00 soft=0.00 pass=1.11 grace=0 heap=164240
2025-12-26 09:50:42 Debug: sdcp_exp=7119.62mm cumul_sns=7060.25mm pulses=2311 | win_exp=23.97 win_sns=21.39 deficit=2.58 | jam=0 hard=0.00 soft=0.00 pass=1.01 grace=0 heap=165440
2025-12-26 09:50:50 Debug: sdcp_exp=7159.33mm cumul_sns=6.11mm pulses=2 | win_exp=11.17 win_sns=6.11 deficit=5.06 | jam=0 hard=0.00 soft=0.00 pass=0.70 grace=1 heap=166228
2025-12-26 09:50:50 Debug: sdcp_exp=7161.72mm cumul_sns=9.16mm pulses=3 | win_exp=13.56 win_sns=9.16 deficit=4.39 | jam=0 hard=0.00 soft=0.00 pass=0.55 grace=1 heap=166228
2025-12-26 09:50:50 Debug: sdcp_exp=7161.72mm cumul_sns=9.16mm pulses=3 | win_exp=13.56 win_sns=9.16 deficit=4.39 | jam=0 hard=0.00 soft=0.00 pass=0.68 grace=1 heap=167416
2025-12-26 09:50:50 Debug: sdcp_exp=7164.04mm cumul_sns=12.22mm pulses=4 | win_exp=15.88 win_sns=12.22 deficit=3.66 | jam=0 hard=0.00 soft=0.00 pass=0.68 grace=1 heap=166052
2025-12-26 09:50:51 Debug: sdcp_exp=7166.17mm cumul_sns=15.28mm pulses=5 | win_exp=18.01 win_sns=15.28 deficit=2.74 | jam=0 hard=0.00 soft=0.00 pass=0.77 grace=1 heap=165844
2025-12-26 09:50:51 Debug: sdcp_exp=7166.17mm cumul_sns=15.28mm pulses=5 | win_exp=18.01 win_sns=15.28 deficit=3.66 | jam=0 hard=0.00 soft=0.00 pass=0.77 grace=1 heap=167448
2025-12-26 09:50:51 Debug: sdcp_exp=7168.42mm cumul_sns=15.28mm pulses=5 | win_exp=20.26 win_sns=15.28 deficit=4.98 | jam=0 hard=0.00 soft=0.00 pass=0.85 grace=1 heap=166260
2025-12-26 09:50:52 Debug: sdcp_exp=7168.42mm cumul_sns=18.33mm pulses=6 | win_exp=20.26 win_sns=18.33 deficit=1.93 | jam=0 hard=0.00 soft=0.00 pass=0.90 grace=1 heap=166064
2025-12-26 09:50:52 Debug: sdcp_exp=7170.43mm cumul_sns=18.33mm pulses=6 | win_exp=22.27 win_sns=18.33 deficit=3.94 | jam=0 hard=0.00 soft=0.00 pass=0.90 grace=1 heap=166068
2025-12-26 09:50:52 Debug: sdcp_exp=7170.43mm cumul_sns=21.39mm pulses=7 | win_exp=22.27 win_sns=21.39 deficit=1.93 | jam=0 hard=0.00 soft=0.00 pass=0.90 grace=1 heap=167448
2025-12-26 09:50:52 Debug: sdcp_exp=7170.94mm cumul_sns=21.39mm pulses=7 | win_exp=22.79 win_sns=21.39 deficit=1.40 | jam=0 hard=0.00 soft=0.00 pass=0.96 grace=1 heap=165844
2025-12-26 09:50:52 Debug: sdcp_exp=7173.02mm cumul_sns=21.39mm pulses=7 | win_exp=24.86 win_sns=21.39 deficit=3.48 | jam=0 hard=0.00 soft=0.00 pass=0.94 grace=1 heap=165844
2025-12-26 09:50:53 Debug: sdcp_exp=7173.02mm cumul_sns=24.44mm pulses=8 | win_exp=24.86 win_sns=24.44 deficit=0.42 | jam=0 hard=0.00 soft=0.00 pass=0.98 grace=1 heap=166276

Expected Behavior

Actual filament measurement should continue to track with expected unless a Jam is detected

Actual Behavior

Actual Filament measurement reset to zero in the middle of a print.

Additional Context

Not sure there were any enviromental or printer/filament factors since the previous version seemed to be functioning well and I am repeating the same prints I have been running for several days. I have attached the entire log in case there is any other relavent data.

logs_2025-12-26T18_18_20.122Z.txt

[coderabbitai]

Coding Plan

Approach

The filament motion sensor's cumulative measurements are being reset mid-print in v0.8.0-alpha, causing tracking to restart from zero. Log analysis shows this occurs when the grace period activates (grace=1), indicating spurious resume detection is triggering sensor resets during active printing without actual pause/resume events.

Observations

The system uses a three-layer architecture: FilamentMotionSensor tracks pulse-based filament motion with cumulative counters, JamDetector implements jam detection logic with grace periods, and ElegooCC coordinates the state machine that manages printer status transitions and sensor lifecycle. ElegooCC responds to SDCP printer status updates and triggers sensor resets during legitimate pause→resume transitions. The current implementation uses a sticky hasBeenPaused flag that remains true after any pause, causing false resume detection when printer status messages are delayed or duplicated.

Assumptions

Assumption 1: Should resume detection require an actual state transition, or is the current sticky flag approach acceptable?

Options Considered:

• Maintain sticky flag approach with additional timeout/debounce logic
• Require explicit state transition from PAUSED to PRINTING for resume detection

Chosen Option: Require explicit state transition from PAUSED to PRINTING

Rationale: This aligns with standard state machine patterns where actions trigger on edge transitions rather than level conditions, provides more predictable behavior under network delays, and eliminates the entire class of spurious reset bugs. Developers working with state machines expect transitions to be triggered by state changes, not by "was ever in this state" flags.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Fix Spurious Resume Detection in ElegooCC

This phase modifies the ElegooCC state machine to detect resume events based on actual printer status transitions rather than a sticky flag, eliminating false positives that cause mid-print sensor resets.

Task 1: Add Previous Status Tracking

Track the previous printer status to enable transition-based resume detection.

• Add previousPrintStatus member variable to ElegooCC class (in ElegooCC.h)
• Initialize to SDCP_PRINT_STATUS_IDLE in constructor
• Update previousPrintStatus at the end of handleStatus() method after processing state transitions

Task 2: Implement Transition-Based Resume Detection

Replace sticky flag logic with explicit PAUSED→PRINTING transition detection.

• Modify resume detection logic in handleStatus() method (around line 317-323 in ElegooCC.cpp)
• Replace condition if (jamDetector.isPauseRequested() || hasBeenPaused) with transition check: if (jamDetector.isPauseRequested() || (previousPrintStatus == SDCP_PRINT_STATUS_PAUSED || previousPrintStatus == SDCP_PRINT_STATUS_PAUSING))
• Remove hasBeenPaused flag entirely from ElegooCC class (remove member variable declaration, initialization, and all assignments)
• This ensures sensor reset only occurs when printer actually transitions from paused state to printing state, not on duplicate PRINTING status messages

Task 3: Add Diagnostic Logging for Sensor Resets

Enhance logging to make future debugging of reset issues easier.

• Add log statement before calling motionSensor.reset() that includes: previous status, current status, and whether reset was triggered by jam pause request or state transition
• Add log statement in FilamentMotionSensor's reset() method (around line 8 in FilamentMotionSensor.cpp) that logs the cumulative values being cleared: totalSensorMm, pulses, and sensorMmAtLastUpdate
• This provides clear audit trail when resets occur and helps identify any remaining edge cases

🤖 Prompt for AI agents

Fix the spurious resume detection bug by implementing transition-based state
detection in ElegooCC.

In ElegooCC.h:
- Add `previousPrintStatus` member variable

In ElegooCC.cpp constructor:
- Initialize `previousPrintStatus` to `SDCP_PRINT_STATUS_IDLE`

In ElegooCC.cpp `handleStatus()` method:
- Replace the resume detection condition `if (jamDetector.isPauseRequested() ||
hasBeenPaused)` with transition check: `if (jamDetector.isPauseRequested() ||
(previousPrintStatus == SDCP_PRINT_STATUS_PAUSED || previousPrintStatus ==
SDCP_PRINT_STATUS_PAUSING))`
- Add log statement before `motionSensor.reset()` that includes previous status,
current status, and reset trigger reason
- Update `previousPrintStatus` to current status at the end of the method after
processing transitions
- Remove all references to `hasBeenPaused` flag (declaration, initialization,
assignments)

In FilamentMotionSensor.cpp `reset()` method:
- Add log statement that outputs the cumulative values being cleared:
`totalSensorMm`, `pulses`, and `sensorMmAtLastUpdate`

---

🚀 Next Steps

🤖 All AI agent prompts combined

Fix the spurious resume detection bug by implementing transition-based state
detection in ElegooCC.

In ElegooCC.h:
- Add `previousPrintStatus` member variable

In ElegooCC.cpp constructor:
- Initialize `previousPrintStatus` to `SDCP_PRINT_STATUS_IDLE`

In ElegooCC.cpp `handleStatus()` method:
- Replace the resume detection condition `if (jamDetector.isPauseRequested() ||
hasBeenPaused)` with transition check: `if (jamDetector.isPauseRequested() ||
(previousPrintStatus == SDCP_PRINT_STATUS_PAUSED || previousPrintStatus ==
SDCP_PRINT_STATUS_PAUSING))`
- Add log statement before `motionSensor.reset()` that includes previous status,
current status, and reset trigger reason
- Update `previousPrintStatus` to current status at the end of the method after
processing transitions
- Remove all references to `hasBeenPaused` flag (declaration, initialization,
assignments)

In FilamentMotionSensor.cpp `reset()` method:
- Add log statement that outputs the cumulative values being cleared:
`totalSensorMm`, `pulses`, and `sensorMmAtLastUpdate`

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[Natclanwy]

Had another reset a few hours later in the same print, I don't see any ESP restarts other than the one that occured just before the first reset.

logs_2025-12-26T20_50_42.389Z.txt

[harpua555]

@Natclanwy could you please try v0.8.2-pre2 ? This version is available on the distributor. If you notice another crash, you can get the coredump info by connecting to USB and running espcoredump.py --chip esp32s3 --port <serial-port> --baud 115200 save_corefile core.dump

[Natclanwy]

Just flashed it and started a new print.

[Natclanwy]

Caught a crash, not sure how to proceed.

logs_2025-12-28T18_58_29.797Z.txt

[Natclanwy]

I was able to flash 8.2 and there was a core dump available afterwards not sure if it's from the same event since I'm not sure if flashing will wipe that or not. I did choose to not erase the device when I flashed the update in hopes it would preserve it. Had to append .txt to upload the file.

coredump_2025-12-28T21_35_13.927Z.bin.txt

[harpua555]

I was able to flash 8.2 and there was a core dump available afterwards not sure if it's from the same event since I'm not sure if flashing will wipe that or not. I did choose to not erase the device when I flashed the update in hopes it would preserve it. Had to append .txt to upload the file.

coredump_2025-12-28T21_35_13.927Z.bin.txt

perfect, thanks - I'll take a look tomorrow

[harpua555]

v0.8.2-pre4 contains a fix for the specific crash seen in 0.8.1 - awaiting further crashes

[harpua555]

#102 should resolve this - I believe this was due to immediate crash/reboot cycles instead of a true reset. See further explanation on #100 and reopen this if needed.