You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I use the -p option, I usually get much better estimates of the progress and remaining time on the printer's LCD than the crude percentage that Slic3r calculates as z/z_max. However, the GPX estimate is still way off at the beginning of the print. When slicing a relatively small model, the percentage will already be at e.g. 38% just after the start G-code block, which does nothing but heating the nozzles and extruding a priming line. This definitely does not take 38% of the time of the entire print, especially not if I have preheated. Even for large prints, I still need to multiply the initial time estimate from the printer by 2 to come anywhere near the actual time. I'd rather ignore the start G-code block entirely for the progress estimate, and would like to see a progress of 0% or 1% when the actual print starts.
I thought the @body macro ignores everything before it, but it does not seem to affect the progress estimate in any way. Neither does removing any M73 commands from the start G-code.
I have found the broken @header and @footer macros in the source code, maybe they can be made useful to implement this kind of feature.
The text was updated successfully, but these errors were encountered:
@Header, @footer and @Body were designed to ignore @macros in the header and footer for things like pauseatz since people often have a few Z moves in their header. As you note header and footer don't work and body only works right in offline mode since header starts out on.
The time estimate includes a random guess about heatup. Your first request is just to remove that. The other implied request is to make the estimate more accurate and the main discrepency there is gpx doesn't take into account the parts of each segment that are slower due to acceleration. So the faster you print and/or shorter segments, the more the estimate is wrong.
When I use the -p option, I usually get much better estimates of the progress and remaining time on the printer's LCD than the crude percentage that Slic3r calculates as z/z_max. However, the GPX estimate is still way off at the beginning of the print. When slicing a relatively small model, the percentage will already be at e.g. 38% just after the start G-code block, which does nothing but heating the nozzles and extruding a priming line. This definitely does not take 38% of the time of the entire print, especially not if I have preheated. Even for large prints, I still need to multiply the initial time estimate from the printer by 2 to come anywhere near the actual time. I'd rather ignore the start G-code block entirely for the progress estimate, and would like to see a progress of 0% or 1% when the actual print starts.
I thought the
@body
macro ignores everything before it, but it does not seem to affect the progress estimate in any way. Neither does removing any M73 commands from the start G-code.I have found the broken
@header
and@footer
macros in the source code, maybe they can be made useful to implement this kind of feature.The text was updated successfully, but these errors were encountered: