incorrect print time estimates (S3D), layer count etc
-
Hi,
I use S3D v4.1.2 (or whatever the most recent is) and I have not encountered that problem. The worst I have seen is being off by one layer.
And I have never had the printer keep running long after the firmware reports the printing is done.
But I have not tried the v2 of DWC as I haven't seen a official release yet - just RCs.
We need to see any gcode you have that is executing at the start and end of printing.
In my case I have two macro files (print_begin.g & print_end.g) that are executed by S3D. There is no other start/end code in S3D other than the call to these two macros.
As to time estimates they will never be more than estimates.
Frederick
-
@vlad said in incorrect print time estimates (S3D), layer count etc:
Why would I want to split my gcodes and do macros for an obvious bug in DWC?
I do it so that my start and end gcode is the same no matter what slicer I'm using and if I want to change it I only have to change it in one place.
Regardless, the "Why" it's happening is as nhof describes. The Z move at the end of the file makes it think there is more left to print.
The problem is that it's very read intensive to scan and process the entire gcode file. This would be trivial for something like a Raspberry pi, but the microcontroller of the Duet isn't suited to things like that. So it looks at the start of the file and the end of the file for markers to use in it's estimates. It's not particularly sophisticated, so it's easy to confuse. Definitely room to improve. Agree 100%. Thanks for uploading the example file to verify the problem.
@vlad said in incorrect print time estimates (S3D), layer count etc:
None of my other boards have such issue, including 8bit cheap boards.
Do they also give you 3 ways to estimate the file completion?
@vlad said in incorrect print time estimates (S3D), layer count etc:
All boards calculate percentage correctly.
I would wager that even in this case the file time estimate or the filament remaining estimates were at least close to correct.
-
@nhof said in incorrect print time estimates (S3D), layer count etc:
It would be possible of course for DWC/RRF to change to use just the file size based percentage estimate (this is what Marlin uses, and RRF calculates this as well).
The GCode M532 is intended exactly for this purpose, the slicer being able to provide to the printer progress status in percentage.
It work great for example when using Simplify3D and the Sailfish firmware.
Coming from Sailfish, having three different time left estimates in Duet is kind of odd.
EDIT: just checked a gcode file generated by S3D for Sailfish firmware, the percents markers are M73 codes, not M532.
-
@phaedrux don't really care about "ways to do it" being a consumer. All I want is a solution for an accurate estimates, and I am expecting a $360 product at least do that. I am not here to mess with board firmware. I have other things and tasks daily. Bottom line is $20, way less capable boards do estimate same exact gcode correctly (I am printing some mass production on several printers currently) and Duet does not. This is the problem and it should be addressed.
-
@vlad My god you're an insufferable twat. I'm through trying to help you.
-
@phaedrux and you are apparently a swallower, if you are ok having to do manufacturer job yourself. Don't expect everyone to be like you then. I simply value my time. I am here to report issues and expect them fixed, not to try to workaround them myself. Everything you said is dead basic, you think those advices were in any way a help? I post here for management to see issue reported, not for random dude like you advice obvious things and then complain about me not willing to do duet3d job on my own. You have nothing to do with this report, I have not asked you for anything, not sure why you are even here commenting. Just keep going with your day. Find something useful to do with your life.
As a side note, I am sure you have never said "nsufferable twat" any man in person. Right? What a brave man
Couch braveman with virtual big balls. 
-
@nhof It's not something that affects my daily printing a lot. The reason for this post is to simply report it to management. I can live with that for a while, it's not a big deal, as long as it is being fixed. I have been experiencing this for years I think, this is why came to report finally. I am not a firmware programmer, so all I see as a consumer is that only duet has this problem for some reason. So, I am here to report the bug. Hope David can have a look or somebody else from Duet3D.
-
I noticed the same issue with my jobs after I added a G1 command to move the print-head up away from the model after printing - the Duet counted the post-print Z move as layers.
There were two solutions I found:
- You can add the character "E" to a comment after any G1 move you don't want counted toward the layer total on the Duet3d, like this:
G1 Z100 ;This move counts toward the layer total.
G1 Z200 ;E This move does not.- You can put any non-print Z moves in a macro and call that with M98. The macro will not be counted in the layer total:
M98 P"macros/pre_print.g" ; nothing in this macro file counts towards layers
; Start of job "object.g
... ; G1 Z moves here count towards layers
; End of "object.g"
M98 P"macros/post_print.g" ; nothing in this macro file counts towards layers. -
Hello @Vlad
I do understand your frustration with the issues you are running into (I have built many industrial automation machines and dealt with my fair share of supplier woes), however I do think your approach towards getting them solved may be less than productive.
For example, posts such as 'Half-assed update...' and others could be considered unprofessional, and might even damage goodwill with both the Duet team and the community here. Even while dealing with trying issues it's good to remember that we're all human, and to try and find professional ways to communicate frustration.
It's also important to keep in mind that this is a public forum and is frequented by people in the 3D printer community and industry (which is surprisingly small). As a business owner yourself, I'm sure you're aware of the importance of maintaining professional image, and that it does not just apply in the context of communicating with your own customers, but also in dealing with suppliers and others. We would hate to see your reputation tarnished by a few trivial comments written in haste.
I don't personally hold ill will toward you or anyone. I'm writing this simply because I made these same mistakes in a past life, and hope that my hard-learned lessons might be of service to a newer player.
-
@vlad said in incorrect print time estimates (S3D), layer count etc:
As a side note, I am sure you have never said "nsufferable twat" any man in person. Right? What a brave man Couch braveman with virtual big balls.
I'm not one to stand down to the likes of you. If you behaved in person the way you've behaved here I'd have said exactly the same thing to your face. If there's anyone acting tough behind a keyboard here, it's you.
I get that you have high expectations, but your inability to communicate with others in a cordial tone is doing you no favours. I and many others have tried to help you and you've shared very little good will in return.
-
@phaedrux said in incorrect print time estimates (S3D), layer count etc:
Do they also give you 3 ways to estimate the file completion?
Estimations are like weather forecasts, we need just one
DWC is a great board but when it comes to progress and estimations, it's lacking compare to some other 8 bit boards. Here for example it ranges from 1:18H to 7:45H. https://i.imgur.com/yWE0ZQC.png
I wish I could display only one of those and have it also controlling the progress bar.
-
Hi vlad, You still not taking the happy pills!
Every thread you start ends in abuse from you> -
@zapta what other 8 bit boards? As far I am aware no 8-bit board have any kind of progress and time es terminations. They only have a file progress bar when printing from SD-card.
-
Hi,
Can you show us an example of an "accurate" 8 bit board?
Before settling on the Duet family I tried many other boards - I don't recall any with an "accurate" display of time remaining.
Frederick
Printers: A FT-5 with the 713 upgrade bits, a custom MarkForged style, a small Utilmaker style, a small CoreXY from kit and a E3D MS/TC setup. Various hotends. Using Duets (2 and 3) running 3.4.6
-
@phaedrux You have the power against these kind of people, the power of silence
-
@whosrdaddy said in incorrect print time estimates (S3D), layer count etc:
@phaedrux You have the power against these kind of people, the power of silence
Yup - that works for me.
-
@phaedrux You have the power against these kind of people, the power of silence
Different strokes for different folks. Sometimes it's useful to call out bullies and rude behavior.
-
This post is deleted! -
Can you show us an example of an "accurate" 8 bit board?
@fcwilt (and @dragonn), yes, my other printer, Flashforge Creator Pro, 8 bit Mighty Board with Sailfish firmware. It uses the percentage marks that S3D includes in the file in form of M73 commands. Simple and effective.
This is how the code looks like
-
@zapta Is that using file remaining percentage, or is it based on a path planner estimate of what the actual print moves will take to complete?
Slic3r PE also supports M73 time estimates, but it bases the estimate on a very accurate print time estimate based on using the marlin path planner for actual print times.
From the Slic3r PE 1.41 Alpha 2 release notes:
https://github.com/prusa3d/Slic3r/releases/tag/version_1.41.0-alpha2Support for the "Time to end of print" G-codes
Starting with this release, the time estimator emits a new M73 code for the Marlin firmware flavor at minute intervals, informing the firmware about the time to end of print in both normal and silent mode. Since the 3.3.0 release, the Prusa i3 MK3 firmware is able to display the accurate estimate of the time to the end of print by interpreting this new M73 code.The format of the new M code is the following:
M73 Pxxx Qxxx Rxxx Sxxx
where P is the percentage of the total time already printed in normal (aka full power) mode, R is the time remaining for normal mode in minutes, Q is the percentage of the total time printed in the stealth mode, and S is the time remaining to the end of print in the stealth mode.
Suppressed for gcode flavors other than Marlin
