Prusa-firmware: M300 no longer behaves the same in 3.6.0 Bug?
Just installed 3.6.0 on a newly built MK3
Upgraded another MK3 from 3.4.1 to 3.6.0
Upgraded a MK2.5 from 3.5.1 to 3.6.0
and they all suffer the same change to M300
I have a tone that plays before the print starts so I can check everything is ok for the first layer. This helps me avoid babysitting during heatup.
M300 S783 P400 ; Beep
M300 S1567 P200 ; Beep
M300 S1 P100 ; Beep
M300 S1567 P100 ; Beep
M300 S1 P100 ; Beep
M300 S1567 P100 ; Beep
M300 S1 P100 ; Beep
M300 S1567 P100 ; Beep
This almost sounds monotone now.
tetraDB
All 6 comments
I can confirm, there is no variation in the frequency of the tones any more.
JagerSprinkles
on 10 Mar 2019
I am also confirming the problem.
halofx
on 16 Mar 2019
Can also confirm- tone length and spacing seems correct, but pitch never varies.
eoh7678
on 16 Mar 2019
The culprit seems to be this change: https://github.com/prusa3d/Prusa-Firmware/commit/ff35119ef30f5dc1be813fabf17157b37322d497#diff-df5e16bf433c533f96a37bdb3456d6c9R7495.
The sound generation code branch that respects the pitch was disabled by that change. The commit message indicates that the change targetted filament management, so that might be unintentional?
/cc @MRprusa3d
I was wrong. Disregard my assessment.
fawick
on 28 Mar 2019
So, after taking another look I think this is the commit that broke it: https://github.com/prusa3d/Prusa-Firmware/commit/93d412816308b085982ef6d69734c1ee16cbc8d4. The commit sacrifices the pitch PWM of https://www.arduino.cc/reference/en/language/functions/advanced-io/tone/ to workaround a problem with the timers.
Not sure whether @XPila can do anything about it.
fawick
on 1 Apr 2019
Using timer2 for the system clock was not a very good choice since the avr Tone library uses timer2 on a mega2560 by default. One fix would be to make a custom version of Tone.cpp to use timer3. I dislike that choice since it involves having to maintain a custom version of Tone. The other choice is to leave timer2 alone and move the system clock to timer3. This could be a problem if using Servo.cpp in the firmware but PR doesn't - at least AFAIK.
I have made the change to timer3 in a private build which has been working well for several days now and my tones are back - yea! Proof-of-concept.
thess
on 7 Apr 2019
Related issues
ulab
路
3Comments
duartemv
路
5Comments
anilrobo90
路
3Comments
NoNme1
路
4Comments
erikcramerjr
路
4Comments
Most helpful comment
Using timer2 for the system clock was not a very good choice since the avr Tone library uses timer2 on a mega2560 by default. One fix would be to make a custom version of Tone.cpp to use timer3. I dislike that choice since it involves having to maintain a custom version of Tone. The other choice is to leave timer2 alone and move the system clock to timer3. This could be a problem if using Servo.cpp in the firmware but PR doesn't - at least AFAIK.
I have made the change to timer3 in a private build which has been working well for several days now and my tones are back - yea! Proof-of-concept.