-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
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
Two strategies to address a stuck buzzer #4265
Conversation
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(); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
…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.
…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.
Addressing #4248
ELAPSED
macro for robustitudebuzzer.tick()
during the quick-feedback delayendtime
rather thantimestamp