Planner timing

[AnHardt]

I build my own timer for the planner.

Sometimes i get similar results as @Sebastianv650, but mostly total different. The values include the time used by the stepper interrupt. With the same model, depending on the feedrate i can get maximum times from 4 to 20ms and averages from 2 to 8ms. Without any ADVANCE.

In a second step i minimized the time for the stepper-ISR by short cutting it. Then, for the same model i get now max at 4ms and average at 1.73ms for the planing time + the remaining interrupts.

Sadly non of this value can be used for MIN_BLOCK_TIME the variation is too big.

(cc @thinkyhead, @Sebastianv650)

[Sebastianv650]

Personaly I would use micros instead of millis. For the 20ms region it will not change anything, but an average of 1.73ms where each result has a resolution of 1ms is critical in my eyes.

It's true, the runtime can vary a hughe amount. That's why I was measuring only XYE moves and only displaying the average time over 100 calculations, combined with one gcode section as a "benchmark". The 6ms min. block time was working for me - but I have only one printer to test. The reason for it was SLOWDOWN wasn't working for me due to the long time a update of the LCD took. It's on my list to tests with the new RCBugFix and slowdown again this weekend. If it runs my short moves test gcode without a buffer underrun, maybe we can get rid of the ensure smooth moves thing. Again, I have only one cartesian printer with one specific display - sadly I can't say how it perfoms on other configs.

[AnHardt]

Having seeped abut this, i see, timing the planner with the shortcut in the stepper-ISR is crap. Having always 0 planed moves in the buffer prevents from recalculating already planed moves - so alters the result considerably. :-(

I really like the idea of stopping the display updates when we are in danger the buffer is running dry. But for finding a good criteria when this is the case, i have no good idea. Ether is shuting nown the updates much to early or not not early enough.

[Sebastianv650]

I think there is no perfect solution. Marlin doesn't know what will come next with it's small buffer. Maybe it would work better for a printer with a random configuration and display to keep track of the update runtime on it's own? The display update could track the maximum needed time for an update, starting from 0 on a new print. Then, long_move() could compare the theoretical runtime of the buffer (which will always be longer in reality due to acceleration and deceleration) to the calculated max. runtime. So it could eleminate the need for a given value in the config.

The second parameter with min. segment time can be omitted if slowdown does a good job. I will try testing slowdown today if it can prevent a buffer underrun in all situations.

[Sebastianv650]

Maybe I'm doing something wrong? No mater what I'm trying, I can't get the buffer to 0 with the new LCD updates. I'm using a modified ADVANCED_OK to display the buffer status. Instead of displaying the free space, I changed it to display the used space because that's easier to see a low number. I also tested an alternative where I set a flag if current_block = planner.get_current_block(); isn't able to get a new one.

Even with SLOWDOWNdisabled I don't reach 0. I have no idea why, but I take it as a good sign...

[AnHardt]

Replaced by https://github.com/MarlinFirmware/Marlin/pull/5495