KevinOConnor

Thanks. Interesting. I can understand the value in exporting this information. Some high-level comments: 1. We haven't historically exported the `stepper_x` sections to the status reference. But I guess there...

> This is because the MCU_stepper for the extruder collides with the extruder printer object. The renaming is generic, but currently this is the only case where the status entry...

Sorry for the delay. The only reason for the delay is time constraints on my side. Unless I'm missing something, this PR would break the `[extruder_stepper]` code - as it...

Thanks. As high-level feedback, I'm not sure this is worth the complexity of fixing. A simpler fix may be to not deploy Klipper into a directory with spaces in it....

Thanks. I guess I'm still not sure on this. It seems simpler to me to just install Klipper in a directory without spaces. I'm also concerned about other tools and...

Thanks, but I'm not sure this is a good fit for the Klipper master branch. As high-level feedback, it seems a bit "esoteric" and I'm not sure it is worth...

FWIW, there is already a timestamp available (`printer.toolhead.estimated_print_time`). If desirable, we could add another (static) variable somewhere with the estimated system time that the mcu was last reset. (Thus, `unixtime...

> Got to say, I would have never guessed what estimated_print_time is actually for!! That's why it is undocumented - it's a terrible name. Although undocumented, it is used in...

It's possible to add these fields to the toolhead object, but the toolhead.py code is already very complex. I'm a little leery of adding unrelated complexity to it. Another option...

Just initialize `last_print_start_time` and `last_print_start_ostime` with appropriate values at startup. (The existing `printing_time` value is always zero when `state != "Printing"`, so seeding initial values has no impact on it.)...