Avoid print speed oscilations when printing fast detailed arcs.

[mkbel]

Current firmware algorithm slows down up to Minimum segment time. Because there is some computation power margin buffer starts to be refilled in that moment up to moment printer speeds up, drains buffer and slows down again. So if you are printing high polygon count cylinder in high speed, printer is periodically slowing down and speeding up and it has some impact on surface finish. My proposed change is to lock speed to maximum sustained rate when the buffer is drained and don't speedup until segments with higher sustained speed are to be planned regardless of buffer filled earlier.
Video before
Video after
example gcode

[wavexx]

I still need to try this, but what do you think about adding a SLOWDOWN_DEBUG define to trigger a beep if slowdown (at any speed) is triggered, along with some basic info (like the multiplier applied)?

This is similar to what we do in stepper if we overrun the timer.
Ideally we would never want to slow-down, if possible.

[nordurljosahvida]

I still need to try this, but what do you think about adding a SLOWDOWN_DEBUG define to trigger a beep if slowdown (at any speed) is triggered, along with some basic info (like the multiplier applied)?

This is similar to what we do in stepper if we overrun the timer.
Ideally we would never want to slow-down, if possible.

From a user perspective, this would be ideal

[mkbel]

@nordurljosahvida I need more info about your problem flashing this. E.g. log from slicer, which file you are flashing, which printer do you have in order to help you.

[nordurljosahvida]

Thanks @mkbel . [now] flashing a very slightly modified version of 3.9.1 stable, with baudrate set to 250000, #define PLANNER_DIAGNOSTICS and your modified planner.cpp on my MK3Ss.

Here is the log of two flashes.

Here is my what I'm using, and here is the diff relative to main MK3 v3.9.1 stable.

Thanks!

[mkbel]

@nordurljosahvida
Short story:
I would expect this change:
- #define BAUDRATE 115200
+ #define BAUDRATE 250000
Is causing second stage of flashing failing.
If you are using your printer in English language, you can ignore this problem and use it as is, as firmware was successfully flashed and only flashing of external SPI flash, which is used to store user interface strings translated to other languages than English, has failed.

Long story:
From your log I can see that flashing processor firmware was successful and flashing of external SPI flash has failed. It is because your bootloader is unmodified and it communicates with baudrate 115200, so Prusa-Slicer is successful in flashing processor firmware. Next stage of flashing is not done by the bootloader but it is done by the application. As you modified application baudrate to 250000 Prusa-Slicer is unaware of it and tries to communicate with original 115200 baudrate and communication fails. Second stage of flashing is not very critical, so you can ignore this problem. It is needed only if you use your printer in other user interface language than English. If you want to fix this problem, you would need to modify baudrate parameter of last avrdude call from Prusa-Slicer.

- avrdude-slic3r -v -p atmega2560 -c arduino -P /dev/ttyACM1 -b 115200 -D -u -U flash:w:1:/home/x/prusa-firmware-3.9.1-mk3s-tillverka-nz-2020-10-01-slowdown.hex:i
+ avrdude-slic3r -v -p atmega2560 -c arduino -P /dev/ttyACM1 -b 250000 -D -u -U flash:w:1:/home/x/prusa-firmware-3.9.1-mk3s-tillverka-nz-2020-10-01-slowdown.hex:i

[nordurljosahvida]

Thank you so much! I'm sorry for slightly derailing the case by stating that the version without your PR's contents was working, i was sure I had gotten it flashed successfully without, but apparently i cannot reproduce that. I had started suspecting that might have been the issue, thanks as well for providing the CLI command to execute. How can I help feedback-wise with 6 MK3Ss running your code?

[mkbel]

@wavexx

I still need to try this, but what do you think about adding a SLOWDOWN_DEBUG define to trigger a beep if slowdown (at any speed) is triggered, along with some basic info (like the multiplier applied)?

This is similar to what we do in stepper if we overrun the timer. Ideally we would never want to slow-down, if possible.

I don't see any point in that. If you print detailed enough model fast enough you will always get slowdown as the parser and planner is not fast enough on this CPU. The slowdown is no problem as long you have your maximum sustained rate set correctly (minsegmenttime). When I was testing it default minsegmenttime was set correctly for print from SD card. As far as I remember there is about 20% reserve with default minsegmenttime when printing from SD. If you print from Octoprint at 115200 bauds you need to increase your minsegmenttime to avoid complete stops in movement.