-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zero-extrusion ironing moves ignored leading to gross underestimate of print time #258
Comments
I think that I can understand what's going on here. Yes, the PTG compensation is not going to behave well with this ironing! PTG divides your print into three sections: warm up, printing, and cooldown. PTG has a very accurate printing simulator so it can usually figure out the time to print very well. warm up and cooldown are much harder. So what PTG does is observe how long your printer spends from the start of a print until at least 5 mm of filament is extruded. It also observes how long after the last extrusion and until the end of the print. Those are the warmup and cooldown. In calculations, PTG will assume that the warmup and cooldown takes a consistent amount of time. For the printing time, which is the majority, PTG will scale the printing time by a factor based on the last five prints. The ironing may confuse PTG's compensation calculations because it means that the cooldown time is not consistent. Hmm. So how to fix it? What should PTG be doing? Maybe just observe warmup and consider cooldown as part of the printing? Then it might get the calculation correct? I'm not sure. |
So if I emit a tiny extrusion after the ironing moves (which will do nothing because the filament is already unloaded), will that make PTG consider the ironing as part of the printing phase? Will any size extrusion do? And does retraction count as extrusion? This would be easy for me to do. Another idea would be for PTG to detect the end of the printing phase as being the last extrusion - or, if there's a lot of gcode after that, the point at which the nozzle temp is set to zero. In most prints, the distance (in lines of gcode) between last extrusion and nozzle temp to zero is surely a few (maybe 10's) of lines. In my case, there are 100's (or 1000's) of lines between those two events. Perhaps that's not a bad heuristic? Or as you say, simpler to ditch the cooldown concept altogether. Perhaps you can look at stats to see how long that phase is in real usage. I suspect it's normally very short (less than 1 minute?), so absorbing it in to printing time would be ok. |
Describe the bug
For some of my prints, as part of my pre-print toolchain, I modify the gcode output from PrusaSlicer using my own custom software to add a sequence of moves at the end of the print, after filament unload (I use MMU2S). These moves perform an ironing-like function, and have zero extrusion. It would appear that PTG ignores these moves (or wildly underestimates their duration). Given that the time estimates from PrusaSlicer are useless in this scenario, it would be great if PTG got it right. As it stands, PTG underestimates the print time by about 50% (~2hrs estimate vs ~3hrs actual). "Learning" from this, PTG then applies a big correction factor to subsequent prints, including prints that don't have the custom ironing moves, thus it gets the duration of pretty much everything I print substantially wrong. Log and gcode attached.
In the attached gcode, the custom moves start at comment line
; TG_IRONING start
and end at; TG_IRONING end
.Actual total print time was 3h01m06s. PS estimate was 1h11, which was probably reasonably close excluding the custom ironing moves, so custom ironing moves took around 1h50.
gcode.zip
log.zip
OctoPrint Version:
1.6.1
PrintTimeGenius Version (if you know):
2.2.8
The text was updated successfully, but these errors were encountered: