Use klipper estimate from klipper_estimator in SuperSlicer

[GijsvanDulmen]

Is your feature request related to a problem? Please describe.
I'm using the nice program dalegaard wrote to get better estimates for my prints. It uses postprocess and prints the estimated time inside my generated gcode. This seems to be extremely accurate. Before I got like 6 hour estimates to be 3 hours in real printing time.

The estimator:
https://github.com/Annex-Engineering/klipper_estimator

Describe the solution you'd like
I would love if there was a feature to enable to get the estimated time from the generated post-processed gcode again after my print is sliced and to show up in SuperSlicer.

Describe how it would work
Read the following line from the gcode:
; estimated printing time (normal mode) = 2h 50m 47s

And show it in SuperSlicer.

Describe alternatives you've considered
Accepting the way it is and get stress when I start a print at 19:00 of which the estimate is 6 hours. Don't know if I will be able to sleep on time ;-)

Additional context
None.

[supermerill]

Erf.
If he has make it in c or c++, i could have use it as a lib.
I don't have time to learn rust to rewrite it.
Can he do a c++ version?

[GijsvanDulmen]

Maybe, I could ask. But I was more thinking about just reading back the estimate from the gcode. That would allow for sort of a an interface between superslicer and post-process scripts. Does that seem like a way to go?

[matthewlloyd]

Looking at the code in SuperSlicer's GCodeProcessor.cpp and klipper-estimator's planner.rs, since they both use trapezoidal move queues for planning, would it be faster and a better solution to implement Klipper's kinematics directly in C++ in GCodeProcessor.cpp? Then everything would be integrated, and SS could expose square corner velocity and max accel to decel settings in the UI alongside the existing Marlin jerk settings. @dalegaard

[supermerill]

would it be faster and a better solution to implement Klipper's kinematics directly in C++ in GCodeProcessor.cpp?

Ideally extracting all the time-stuff (timemachine, timeprocessor and code that aren't inside them but should) into a "TimeProcessor" class
then, we can implement it with the current marlin code & another one with klipper stuff.

But if using some if(==klipper) at some points is enough and much less work, I won't complain.

SS could expose square corner velocity and max accel to decel settings in the UI alongside the existing Marlin jerk settings.

yes

[michaelmyc]

I think C++ and Rust can interop, though I'm not super familiar with the topic and have 0 experience in Rust. https://hsivonen.fi/modern-cpp-in-rust/

[LeLocTai]

Is there any reason we have to port the code instead of just calling the binary?