Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Two strategies to address a stuck buzzer #4265

Merged
merged 2 commits into from
Jul 11, 2016

Conversation

thinkyhead
Copy link
Member

@thinkyhead thinkyhead commented Jul 11, 2016

Addressing #4248

  • Use the ELAPSED macro for robustitude
  • Call buzzer.tick() during the quick-feedback delay
  • Specify endtime rather than timestamp

@thinkyhead thinkyhead merged commit 6121c90 into MarlinFirmware:RCBugFix Jul 11, 2016
@thinkyhead thinkyhead deleted the rc_buzzer_patchup branch July 11, 2016 02:46
if (this->state.tone.frequency > 0) this->on();
}
else if (millis() >= this->state.timestamp) this->reset();
else if (ELAPSED(millis(), this->state.endtime)) this->reset();
Copy link
Contributor

Choose a reason for hiding this comment

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

Use the ELAPSED macro for robustitude

This is subjective Scott, we don't have to use macros everywhere. In fact we should prefer to use plain standard C code which everyone can read instead of custom macros.

Copy link
Member Author

@thinkyhead thinkyhead Jul 12, 2016

Choose a reason for hiding this comment

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

Actually, this matters. I didn't think so either, but I came up against it.
So this macro actually enforces a necessary methodology.

Copy link
Contributor

Choose a reason for hiding this comment

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

Does it have to do with the cast to long ?
millis() and state.timestamp should be both of them long.

Copy link
Member Author

@thinkyhead thinkyhead Jul 13, 2016

Choose a reason for hiding this comment

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

I'm not sure I remember all too well. At that time I made test code to run random time values in a loop. I believe that the cast to long in the PENDING macro is just there to allow a comparison using var < 0. The compiled code probably just tests the high bit.

@jbrazio jbrazio modified the milestone: 1.1.0 Jul 18, 2016
@thinkyhead thinkyhead mentioned this pull request Jul 25, 2016
drewmoseley pushed a commit to drewmoseley/Marlin that referenced this pull request Nov 8, 2023
…arlinFirmware#4265)

Fixed printer_smodel_check for non MMU machines
Commit 136ef96 broke the compatibility check for MK3S without MMU.

May have fixed bug for older MMU machines.
Only comparing up to the length of the value from the g-code, would return equal on older MMU machines trying to run g-code sliced without the MMU.
Unfortunately if that is a feature, it will cause the different printer warning.
drewmoseley pushed a commit to drewmoseley/Marlin that referenced this pull request Feb 10, 2024
…arlinFirmware#4265)

Fixed printer_smodel_check for non MMU machines
Commit 136ef96 broke the compatibility check for MK3S without MMU.

May have fixed bug for older MMU machines.
Only comparing up to the length of the value from the g-code, would return equal on older MMU machines trying to run g-code sliced without the MMU.
Unfortunately if that is a feature, it will cause the different printer warning.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants