-
-
Notifications
You must be signed in to change notification settings - Fork 525
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
Time estimate variation from 20m to 1h34m for top layer 0 to 1 config change on small part on Stable release. (Dev release is around 40-45min) #1634
Comments
Seems to be related to ironing speeds. if you turn ironing off then both are roughly the same but with ironing on then one is way different. That would also explain why the top layer 0 or 1 changes it as if zero then you cant iron either. |
OK - thanks for the details. For my education |
Follow up to c) So time estimate is accurate, Dev is taking twice Stable. |
There is some things going on here.
Why dev behave differently than stable:
oh, and you may want to use thin_perimeter_all, at least on the top layer. |
Thanks for getting back to me - for clarity there WAS a 20min difference between stable and prod for the actual printing. I'm still learning the whole 3DP ropes. Related questions (or how do I help myself to get to the same info) a) Are there any tools to visualise / show what the calculated speeds / accelerations are viewing a peice of GCode (assuming there are no machine limits) PS: Really enjoying the SS - took a bit to get my head around the new tech in general, but the access and development is great and calibration elements are really helpful. |
select "speed" on the bottom left box, in the gcode preview
autospeed try to get the same volumetric speed on the whole object. pps: will be fixed now |
Version
Stable 2.3.56 and Dev 2.3.57.1_win64_211008
Operating system type + version
Windows 10
Behavior
Wildly different time to complete between 20m and 1h32m for only a change in Top Layer from 0 to 1 on a small print.
Observation that stable release:
Estimates 20m for with TopLayer=0
Estimates & Take ~1.5hr for with TopLayer=1
Observation that 2.3.57.1_win64_211008 release:
Estimates 41m for with TopLayer=0
Estimates 44m for with TopLayer=1
Seems inconsistent / unexpected variation - normally I trust the estimates pretty well.
Project File (.3MF) where problem occur
V0.1_Door_Handle_1toplayer.3mf.zip
Thanks, Carl
The text was updated successfully, but these errors were encountered: