Revert: handleInput unchanged-demand short-circuit
Reverts a14aa0d. The "skip when demand unchanged" optimisation broke
the live demo: in some real conditions (basin transitions, safety
controller activations) PS sends repeated demand=0 and the optimisation
correctly turned pumps off the first time but then declined to re-act
when conditions changed in a way the test suite didn't cover. Live
result: pumps stayed off even when basin filled to overflow.
The original symptom (pumps stuck mid-ramp under saturated demand) needs
a different approach — likely a pump-side guard rather than an MGC-side
demand filter. Investigating in a follow-up.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -1281,25 +1281,6 @@ class MachineGroup {
|
||||
return;
|
||||
}
|
||||
|
||||
// Skip abort + redispatch when the demand hasn't changed beyond a
|
||||
// small tolerance. PS ticks every 1 s and re-fires the same demand
|
||||
// while the basin level evolves slowly; without this guard, every
|
||||
// PS tick aborted in-flight pump moves before they could finish
|
||||
// (move duration ~0.4 s, abort cycle 1 s, but each abort
|
||||
// immediately re-issued the same setpoint, so pumps got stuck
|
||||
// ramping from the same starting position to the same target
|
||||
// forever). Tolerance is 0.5 % — small enough that real demand
|
||||
// changes still propagate, big enough to filter PS hysteresis
|
||||
// float jitter.
|
||||
const prev = this._lastDemandQ;
|
||||
const unchanged = Number.isFinite(prev)
|
||||
&& Math.abs(demandQ - prev) < Math.max(0.5, Math.abs(prev) * 0.005);
|
||||
if (unchanged) {
|
||||
this.logger.debug(`Demand ${demandQ} unchanged from ${prev}; skipping abort+redispatch`);
|
||||
return;
|
||||
}
|
||||
this._lastDemandQ = demandQ;
|
||||
|
||||
//abort current movements
|
||||
await this.abortActiveMovements("new demand received");
|
||||
|
||||
|
||||
Reference in New Issue
Block a user