OctoPrint-PrintTimeGenius
OctoPrint-PrintTimeGenius copied to clipboard
eyal0
Estimate with Klipper
It would be great to have PrintTimeGenius work with Klipper as well. Klipper is getting more and more widespread and I would love to have a more accurate estimate with it. Please fill this out:
OctoPrint Version: Last version
PrintTimeGenius Version (if you know):
What did you try: to get the right time with Klipper
What happenned: It the right time for Marlin
What did you expect to happen: Proper time estimate for Klipper
Oh yeah I've heard of Klipper. I guess that I'd need to run a Klipper simulation. I would need to read about Klipper to see how it is done...
I think that it would be even easier than the marlin simulation because Klipper already has a good division between the microcontroller code and the Klippy code.
I opened this issue to work with Klipper on this: https://github.com/KevinOConnor/klipper/issues/862
I have a PR ready for Klipper. I am working on incorporating this into PTG now. How do I run klipper from the command-line on an OctoPrint installation so that it will run a klipper simulation?
I can do it on my computer like this:
python klippy/klippy.py config/example.cfg -i test/klippy/move.gcode -v -o /dev/null -d local/atmega2560-16mhz.dict --printline "XXX: bytepos {#filepos} and print time {#print_time} seconds."
Can you try connecting to your Raspberry Pi and typing something like that to see if you can get it to work. It should output a bunch of into about the byte position in print time. When you get that working, let me know what the command line was!
You probably need to replace the .dict file above with the correct value. For the gcode file, pick anything from ~/.octoprint/uploads, and replace the .cfg file with your .cfg file.
Is this still relevant?
I checked out your printline branch and run the following command:
klipper@rpi2:~/klipper$ time ../klippy-env/bin/python klippy/klippy.py ~/printer.cfg -i ~/lrs-350-psu-bracket2-2.gcode -v -o /dev/null -d out/klipper.dict --printline "XXX: bytepos {#filepos} and print time {#print_time} seconds." >../estimate.txt 2>&1
real 0m32.308s
user 0m32.743s
sys 0m1.357s
I used the .dict file produced during firmware build, which is out/klipper.dict .
estimate.txt lrs-350-psu-bracket2-2.gcode.txt
Yup, it works somewhat, but it has some problems. The main issue is that the print time does not entirely match the byte position. It's off by a few seconds and the number is always different, maybe in the 10-20 second range.
The problem is that the byte position and time are when the instruction is sent to the machine, not when it is run. klipper process instructions before it sends them so that it can, for example, group them up and look for ways to optimize. My code is breaking this so the time that is output doesn't match the real time.
I need to find a way to calculate the time so far without breaking this optimization, so that the results are accurate. I haven't figured out how to do that yet and I haven't had time to look into it.
In my discussion with the maintainer of klipper, he had an idea of injected a fake G code and then when that fake Gcode comes around, then print the time and byte position. It's a more complicated solution but it would give a more correct result.
Until I have the time to figure out how to do that, I can't yet solve this bug. ;-(
Any updates? was just chatting about this with some folks, would be really nice to have accurate print time estimates for Klipper
Hey, it's been a while since this was bumped. Any progress on this? Klipper has become more and more popular as late, and I think it would be a good feature to have. :)
The problem is mostly on the klipper side.
The way it works with marlin is that PTG runs a marlin-simulation, racing through the gcode and calculating how long each line will take. I need something like that for klipper but I don't know if klipper added support.
Here's the latest on it: https://github.com/KevinOConnor/klipper/issues/2124
I don't know if that code was actually added to klipper. I've asked again: https://github.com/KevinOConnor/klipper/pull/890#issuecomment-630262609
Poke at the Klipper maintainer until it gets done and then I'll do the PTG part of it.
It sounds like Kevin added the code that would allow PTG to get the print time to within a couple of seconds. I imagine that would be close enough for almost everyone!
There's a hook in there but it isn't complete. https://github.com/KevinOConnor/klipper/pull/890#issuecomment-630531857
I could try to add it myself and maybe he'd merge it?
@eyal0 Yes I think if you did the work and submitted a PR he would merge it
Should this be working now? Still getting inaccurate print times from PTG with Klipper.
Nope. Klipper doesn't have support for it. I have sort of an idea of how it should be done but I haven't any way to test it.
You shouldn't be sooo inaccurate, though. Does Klipper performance vary from Marlin performance so wildly?
I honestly can't say for sure as I am only a month or so into 3D printing and I converted over to Klipper a couple of weeks ago. What I can say is that I did not notice times being drastically off from what the estimates where that are generated when I slice the files in Cura when I was running TPG with Marlin. Now on Klipper I am seeing things like 10 hours in Cura and PTG with Klipper is estimating 23 hours for example. Or if I run a test print for bed leveling where I know exactly what the print is going to do I can be at 98% or 99% complete and can see that it only has to lay down a line or 2 of print to be finished and the ETL will be something like 6 or 8 min to complete when it actually finishes within a min or so. I totally could have something not set correctly but I don't know what I should be looking for in that is the case.
For my use case, slicer-generated and Marlin-simulated estimates are usually significantly off (sometimes by hours) because I use Klipper macros to handle things like filament switches in multimaterial printing. Neither the slicer nor a gcode analyzer would have any way of knowing what gcode gets executed within those macros or how long it should take. The only way to get a reasonably accurate time estimate would be for Klipper itself to calculate the estimated time.
Sorry for chiming in but would be interested in this feature myself.
There's a commit on klipper for an "Advanced" tuning guide here: https://github.com/KevinOConnor/klipper/pull/3158/files
it details the following command:
/klippy-env/bin/python ./klippy/klippy.py ~/printer.cfg -d out/klipper.dict -o /dev/null -i ~/.octoprint/uploads/my_print.gcode
Just wondering if this could be utilised in anyway similar to marlin-calc.
Currently I'm anywhere from 0.1% - 10% out, larger prints seem to be more acurate which is not an issue at all.
That outputs the total time but I need estimates along the way, ideally for each line of gcode.
Any updates on this? I've just moved from Octo to Klipper, and the only thing I really miss is your plug in!
I'm touched.
I'm sort of waiting on Klipper to provide accurate reports of the time to print a file at regular intervals. There needs to be a way to get Klipper to run a simulation and output how long each line of gcode takes to execute.
If Klipper can do that, I can do the rest.
Someone (not me) will need to drive that effort in Klipper.
https://github.com/Annex-Engineering/klipper_estimator - Probably very similar to the Marlin simulation, but for Klipper
@tildebyte does Klipper work with OctoPrint? Or do Klipper users use something other than OctoPrint?
@eyal0 Yes, it does work with a bit of configuration, but a lot of people have moved to using Klipper with Mainsail or Fluidd as they support it significantly better.
I find that Octoprint does everything I need it to do re:klipper :shrug: - the existing plugins support it quite robustly - I see no reason to go through the pain of trying to install moonraker...
Having said that, I have no insight into the popularity of Octoprint amongst Klipper users (though I will point out that Octoprint appears by name in several places in the Klipper docs :D)
Klipper was originally developed with Octoprint as a requirement. Even after Moonraker was released, Octoprint was still the only officially supported Klipper interface. But then the Klipper developer tried Moonraker and now that (plus a frontend) is the officially supported interface.
Personally, Octoprint was always dog slow for me, even with only a couple of plugins. I always assumed the Rpi 3b+ was just doing the best it could. But then I tried Moonraker/Mainsail and was shocked by how fast and responsive it is. I never looked back.
My experience as well. Octoprint is designed for to many things for Marlin that are not useful/detrimental with Klipper suck as feeding G-code line by line. Octoprint is sometimes slower than Klipper can print and the printer hangs waiting for Octoprint. Mainsail uses a Virtual SD method but retains a lot of the controls Octoprint has on the current print (ommit parts, flow, speed coltrols, etc) and all that in a newer and faster platform (TS and Vue I believe)
I realize this is veering OT, but I personally haven't seen anyone give a "this is THE killer feature of (e.g.) Mainsail", so, for posterity...
Octoprint is sometimes slower than Klipper can print and the printer hangs waiting for Octoprint
Never happens for me.
But then I have the great good fortune to have a 2015 MacBook Air with a devastated screen[1] just lying around, which is now happily running Elementary OS, Octo, Klipper, and ustreamer. I could probably drive a second printer if I had one/wanted to
Mainsail uses a Virtual SD method but retains a lot of the controls Octoprint has on the current print (ommit parts, flow, speed coltrols, etc)
OTOH, this is very interesting, as the only reason I don't use the Virtual SD with Ocrtoprint is that I don't wish to give up certain plugin features
(TS and Vue I believe)
IMHO this is NOT a virtue, and: reasonable people can disagree about programming languages, but TypeScript certainly is not inherently a "faster platform"[2]
edit Hilariously, Moonraker, which all the other front ends work through, is written in Python. So the TS/Vue thing is strictly GUI
[1] ssh doesn't care about cracked displays 😁
[2] Unless it's compiled...