Belay does not update

[HjortCreations]

Belay multiplier changes do not affect an already queued/active extrusion move

Summary

When using Belay with extruder_type: extruder_stepper, the high/low multiplier appears to update only for future extrusion moves. It does not seem to affect an extrusion move that is already queued or currently running.

This becomes a practical limitation for external filament feeder systems, where Belay is expected to react to buffer state changes while extrusion is actively happening.

Setup

I am using Belay with an extruder_stepper as an external filament feeder:

[extruder_stepper sheep_feeder]
extruder: extruder
# stepper pins etc.

[belay sheep_belay]
extruder_type: extruder_stepper
extruder_stepper_name: sheep_feeder
sensor_pin: ^sheep_feeder:PB8
multiplier_high: 1.05
multiplier_low: 0.95
debug_level: 1

The external feeder is placed before the toolhead extruder, with a reverse Bowden path between them. The Belay is used as a filament buffer sensor to slightly increase or decrease the secondary feeder output.

Observed behavior

Belay can be enabled successfully:

ENABLE_BELAY BELAY=sheep_belay

The sensor state can be queried and changes correctly:

QUERY_BELAY BELAY=sheep_belay

The issue appears when extrusion is already in progress.

Example test:

M83
G1 E1000 F120

If the Belay sensor state changes while this extrusion move is already running, the high/low multiplier does not appear to affect that active extrusion move. The secondary extruder continues as if the multiplier that was active when the move was queued is still being used.

The multiplier change appears to affect later/new extrusion moves instead.

Expected behavior

When the Belay sensor changes state during extrusion, the secondary extruder multiplier should affect the feeder output as soon as possible, ideally during the active extrusion move.

For an external filament feeder and buffer system, the intended behavior is more like real-time buffer correction:

• Belay compressed during forward extrusion: secondary feeder should increase feed rate.
• Belay expanded during forward extrusion: secondary feeder should reduce feed rate.
• The correction should take effect while extrusion is happening, not only on the next G-code move.

Why this matters

For normal sliced print moves, this may be less visible because the print consists of many short extrusion segments.

However, it becomes a problem in cases such as:

• long UI extrusion moves
• long purge moves
• filament loading/unloading
• vase mode or long continuous paths
• high-flow printing
• external feeder systems with long reverse Bowden paths
• feeder/buffer setups where the buffer can hit its mechanical limit before the next move boundary

In these cases, waiting until the next planned move can be too late.

Current implementation concern

From reading the current implementation, the multiplier for extruder_stepper is applied by changing the secondary stepper rotation distance:

self.set_multiplier = lambda m: stepper.set_rotation_distance(
    base_rotation_dist / m
)

The multiplier is updated when the Belay sensor callback fires:

def sensor_callback(self, eventtime, state):
    self.last_state = state
    if self.enabled:
        self.update_multiplier()

This does update the multiplier state, but it does not appear to modify already planned/queued step generation for an active extrusion move.

Question

Is this behavior expected due to how Klipper/Kalico queues extrusion moves and step generation?

If so, would it be possible to document this limitation clearly?

If not, would there be a way to make Belay correction affect an active extrusion move, or should Belay be considered a move-boundary-based correction system rather than real-time buffer control?

Possible directions

Some possible approaches could be:

1. Document that Belay multiplier changes affect future moves only.
2. Add a warning/example for long extrusion moves.
3. Improve status/debug output so it is clearer when a multiplier changed but cannot affect already queued motion.
4. Investigate whether a different correction approach is needed for real-time external feeder/buffer control.

[rsghosh]

This behavior of multipliers set by Belay affecting future moves but not updating in the middle of a move is expected. Since the Belay software modifies movement of the secondary extruder by modifying its rotation_distance setting, it can only apply modifications each time a batch of moves is flushed from the lookahead queue (right before the rotation_distance gets used in determining step timings for that batch of moves). Moves that have already had their step timings calculated will not be modified later.

It would be more difficult to modify moves that are already in progress while still making the system work with Kalico or Klipper due to how step timings are generated ahead of time. I'm not sure if it's possible while still having Kalico/Klipper be in charge of generating the steps rather than letting a separate program control the secondary extruder.

I have not seen issues reported with the current software approach until now. Are you running a much larger printer/higher flowrates than typical hobbyist machines? I can see how this issue might occur with very long or fast moves as you mentioned. I don't think it would be an issue on filament loading/unloading though, since during a load/unload, there is only a short portion where both extruders are in contact with the filament (at the end of a load or beginning of an unload). Unrelated to this issue, I would recommend disabling Belay before a load or unload and re-enabling it afterwards so the multiplier will be reset to 1 for the long move through the bowden tube, just so that the distance of that move will be consistent regardless of the Belay sensor state.

Some potential things that might be worth trying to make the Belay software work with your setup (these are bandaid solutions, but they might extend how long/fast an extrusion needs to be for syncing to fail):

• Move the multiplier_low and multiplier_high config values closer to 1 (or whatever the ideal multiplier is that would match the primary extruder) - this will limit how fast the Belay's slider can move relative to a given extrusion speed. As always, the values must be set such that you are confident the ideal extrusion multiplier will always lie between multiplier_low and multiplier_high, but the default range of +/-5% is likely much higher than needed as long as your extruders are not slipping inconsistently.
• Use a Belay sensor design with a longer travel - this should allow for more lag/extrusion distance between when a multiplier update ideally would occur and when it actually occurs before the slider hits the end of its travel.
• If the issue only occurs on long straight-line moves that take many times the lookahead flush time (0.250 seconds) to complete, perhaps a gcode post-processing script that splits these moves into smaller ones might end up splitting the move across multiple lookahead flushes, allowing the rotation_distance setting to be adjusted midway. But due to how Kalico/Klipper generates step times ahead of time, there would still be lag between when a multiplier is set and when the multiplier takes effect on a move that is actually being executed, so I'm not sure how much of a difference this would make.

[HjortCreations]

Yes I do run bigger and faster machines than most people, and they are only getting bigger!
I have a 2 meter reverse bowden tube on my printer and pull 8-25kg spools from a drying cabinet 1 more meter away....
I run the Chube Conduction at higher temps to keep flow HIGH on big prints and are chasing the 200mm2/sec mark in my dreams.
With 1mm and above nozzles the lines are almost as big as the filament itself sometimes, and that makes a problem with the current hardware.

For now I have managed to get a OK setup, using almost 3 hours calibrating the secondary extruder VERY finely to the primary and setting the high and low multiplier to 1.01 and 0.99
I feel that the tolerances in this approch is very tight when accounting for reality, heat and weeks of printing in one print.
Deploying this on more machines will be difficult too as the time used on calibrating is high on each mashine and might be different from other extruders of the same model.

Just from observing it, 3 - 4 times the travel would be nice to have, maybe an XL version with two endstops, one for setting the high multiplier and one for the low and in between leave it at 1......

I will take the disable/enable approch with loading and unloading and hopefully that will solve that issue.