Skip to content

Fix for reporting of updated overrides on reset - #994

Merged
terjeio merged 1 commit into
grblHAL:masterfrom
engigeer:PR_report_overrides_on_reset
Jul 26, 2026
Merged

Fix for reporting of updated overrides on reset#994
terjeio merged 1 commit into
grblHAL:masterfrom
engigeer:PR_report_overrides_on_reset

Conversation

@engigeer

Copy link
Copy Markdown
Contributor

Currently it seems that if $676 is configured to clear override values on reset, this change is not reported to a keypad display.

The proposed fix is just a single line addition in the reset loop to set the override reporting flag. This has been tested to work with the RP2040 driver and the latest version of the keypad plugin with I2C display (DISPLAY_ENABLE=9).

Comment thread grbllib.c
sys.override.control.parking_disable = settings.parking.flags.deactivate_upon_init;

flush_override_buffers();
report_add_realtime(Report_Overrides);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Output overrides on changes only?

        if(!sys.cold_start && (sys.override.feed_rate != override.feed_rate || sys.override.rapid_rate != override.rapid_rate))
            report_add_realtime(Report_Overrides);

        do {
            if(spindle_is_enabled(--spindle_num)) {
                spindle_ptrs_t spindle = spindle_get(spindle_num);
                if(spindle->param->override_pct != DEFAULT_SPINDLE_RPM_OVERRIDE) {
                    spindle->param->override_pct = DEFAULT_SPINDLE_RPM_OVERRIDE;
                    report_add_realtime(Report_Overrides);
                }
            }
        } while(spindle_num);

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is OK and would still address the issue I was observing, but I wonder what would be the need to limit so it only sends on changes?

It also seems that sending the message on every reset could maybe be a bit more robust to any other sort of communication errors. That way if there is an issue between the pendant display and ioSender, then issuing a reset command would re-sync things?

If you still prefer to limit it to changes only, I can of course update the PR according to your suggestion above.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is OK and would still address the issue I was observing, but I wonder what would be the need to limit so it only sends on changes?

Not really needed but it is a change from before.

It also seems that sending the message on every reset could maybe be a bit more robust to any other sort of communication errors. That way if there is an issue between the pendant display and ioSender, then issuing a reset command would re-sync things?

Then perhaps Report_All should be used instead? But that may break senders.

@terjeio
terjeio merged commit 8913dd4 into grblHAL:master Jul 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants