Print time estimate #52
Replies: 1 comment
-
Sorry for responding late, I need to remember that GitHub discussions is a thing and I enabled it. 😄 With regard to print time estimates, Kevin and I have discussed this in the past and it is something that we will pursue at some point. I would like to do some benchmarking, while something like this would be ok on a multi-core system, it likely wouldn't run well on a Pi Zero. As such, I would probably implement this separately from extract_metadata.py and only enable it if the system has multiple cores. There are some other things that need to be considered before this could be implemented. For example, Moonraker will need to be able to determine the MCU type so it can pass the appropriate dict file. In the case of multi-mcu configurations Moonraker will need to pass multiple dict files (I'm not sure if this is even possible). I sort of wonder if this is something that could be parsed from the configuration rather than from the command line. It is something that I'll need to discuss with Kevin. |
Beta Was this translation helpful? Give feedback.
-
Instead of relying on a slicer time estimate, it's possible for klipper to give an exact estimate of how long it would take to run a gcode file.
Per https://github.com/KevinOConnor/klipper/pull/3158/files:
~/klippy-env/bin/python ./klippy/klippy.py ~/printer.cfg -d out/klipper.dict -o /dev/null -i ~/.octoprint/uploads/my_print.gcode
would output something like:
INFO:root:Exiting (print time 5107.300s)
What are your thoughts about integrating this into the metadata parsing script? Depending on the gcode file, it can take from seconds to minutes to complete.
Beta Was this translation helpful? Give feedback.
All reactions