Skip to content
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

Feature request: allow ignoring any progress before a certain marker #20

Open
DrLex0 opened this issue Mar 9, 2017 · 3 comments
Open

Comments

@DrLex0
Copy link

DrLex0 commented Mar 9, 2017

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.

@markwal
Copy link
Owner

markwal commented Mar 9, 2017

@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.

@markwal
Copy link
Owner

markwal commented Mar 9, 2017

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.

@markwal
Copy link
Owner

markwal commented Mar 9, 2017

If you're looking to modify source, you're looking for "accumulated.time"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants