incorrect print time estimates (S3D), layer count etc
-
A side question, any plan to use gcode M532 for progress reporting? I used it in the past with S3D and sailfish firmware and it worked pretty good.
-
@vlad I'll bet that there are some G1 Z moves either in your start gcode that are confusing the DWC.
Can you post the first 50 lines or so of the gcode file that is doing this?
-
@phaedrux Well there surely are, because after model is finished bed goes down all the way. But shouldn't a firmware "understand" that those are just bed moves and not printing moves? Bed has to go down, I think it's normal with every printer. Right?
-
Yes it probably should be able to detect that difference but there needs to be a way for it to do so. If you post your gcode file at least we'd have an example of the problem to get an idea of how to fix it.
In the meantime, you have the option of moving those sections of the start and end gcode with the moves into a separate macro and then calling that macro from your gcode. That way when the DWC is parsing the gcode file for details about it, it won't see the confounding G1 Z moves.
-
@phaedrux well, that's not a "proper" solution to a problem. This must be solved inside DWC and not by user workarounds, in my opinion. Why would I want to split my gcodes and do macros for an obvious bug in DWC? None of my other boards have such issue, including 8bit cheap boards. All boards calculate percentage correctly.
-
0_1555629577510_fan x1.gcode here is a file, if you think it can help. But as I said, it simply does what it should do - lowers the bed.
-
This probably has more to do with RRF rather than the DWC specifically.
S3D g-code files do not have any comment strings or setting strings for either total number of layers or object height. So what RRF does is runs through end of the file looking for a Z move and guesses that the last non-relative Z move is the height of the part. This file information is passed to DWC.
In your case the last absolute move is Z=148 so it assumes that is the part height, 148/0.2 is the 740 value you're seeing.
RRF estimates layer-based print time by averaging the last 5 layer times and applying that average time to expected remaining layers. Unfortunately in your case because it expects to print hundreds more layers this will throw the estimate way off.
It might be possible to change the parser to look for the last 'Layer xxx, Z = yyy' comment instead as it might provide a more reliable object height value, but I'm not sure how easy it would be to implement. It would be unreasonable (I think) to re-write the file parser to account for every slicer g-code variation and user g-code input, as it is quite difficult to parse these values from the g-code files given a lack of a standard g-code print info headers and the wide variation among slicers. However it may be reasonable in this case to change given the popularity of S3D.
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). This method will calculate percentage (of file) completed perfectly, but will not provide accurate time remaining estimates.
Here are a couple things you can try in the meantime:
- Try running 'Simulate' on a file from DWC to get a better estimated time. This may result in time estimates during the print being more accurate (I don't really know tho)
- Change your ending g-code to a relative instead of absolute move. If you have your FW travel limits set properly you should be able to do something like this (i have not tested):
G91 ; relative moves G1 Z+500 F900 ; move farther than Z max G90 ; absolute movesRRF should truncate your move at Z max automatically. This will not require splitting g-code by calling up custom end scripts, etc. Obviously it doesn't work if you don't want Z-max specifically but such is life.
I won't argue that DWC/RRF should be improved to better handle these cases, however it's probably lowish priority as a largely UX issue. Depending on where it might be in Duet3D's work list so you may get faster results by using a workaround for the time being.
-
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.
