I’m building a high resolution filament sensor myself (GitHub - EiNSTeiN-/roadrunner-filament-sensor: High resolution filament sensor for 3D printers based on the AS5600 magnetic rotary encoder) and while I’m not using Klipper’s filament_motion_sensor code I used it as a base, and I believe I accidentally stumbled on the answer to your problem.
The motion sensor code calls self._get_extruder_pos(eventtime) which itself ends up calling self.extruder.find_past_position(print_time) every so often to get the estimated extruder position at a given point in time. When an extrusion is requested we should see the extruder accelerate up to speed and maintain a constant speed until the move is done and find_past_position catches up to the requested position. Calling find_past_position repeatedly and graphing the results should produce an approximately straight line going up with a constant slope.
The issue I’m noticing is when I request a long extrusion move, let’s say for example with G1 E45 for the first few seconds find_past_position returns a large value, e.g. it will return 5 for the first 3 seconds right after the G1 command and afterwards start returning linearly increasing values until the 45mm is fully extruded. In other words at the beginning of a move there is a large jump in the expected extruder position which doesn’t catch up to reality for a few seconds.
Going back to your issue, I believe there might be a pulse from your sensor right before a long move occurs, at which point this code is executed:
self.filament_runout_pos = (
self._get_extruder_pos(eventtime) +
self.detection_length)
Which means the filament is detected as “present” as long as self._get_extruder_pos(eventtime) < self.filament_runout_pos. Now because of the behavior I explained above with find_past_position, the estimated extruder position can increase by a value larger than detection_length at the beginning of an extrusion move and trigger the runout code.