New experimental firmware 1.09c-dc42

David, did you ever check the feasibility of running a g-code file without printing to ascertain the expected print time?

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Quote
achaz
I like having multiple print times. I use absolute extrusion and Cura zeroes the extruder roughly every 10000mm, so estimates on filament usage get knocked out of whack.

That sounds like a bug to me. It is trivial to keep a running count of filament consumption whether in relative or absolute mode, and whether there are periodic resets or not. Consider that relative mode is effectively the same as absolute mode with the extruder zeroed after every move. In my experience, time based on filament use is by far the most accurate and I see no purpose in displaying less accurate estimates. The only thing that should prevent it being used is if the total filament amount cannot be found in the G-code. I note that at present the running filament use decreases when there is a retraction. Ideally that should not happen - the filament used should remain the same after a retraction, but start increasing again after the retraction amount has been extruded (though it's not practically significant).

Dave

Indeed Dave, this is a known bug in dc42's fork. Absolute extrusion mode is fully supported in my firmware fork and in fact I introduced a counter variable similar to what you described many months ago. But I'll check again if I can get this behaviour fixed when I start merging in the dc42's new move code.

I for one don't find the third file-based estimation method very disturbing but I agree it isn't very accurate (maybe because a single floating-point variable isn't precise enough?). I think it fits quite nicely in there but if you have any other suggestions what it could be replaced with, please share your ideas so we can discuss them.

Quote
appjaws1
David, did you ever check the feasibility of running a g-code file without printing to ascertain the expected print time?

I implemented that some time ago. See [reprap.org].

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
zombiepantslol
I for one don't find the third file-based estimation method very disturbing but I agree it isn't very accurate (maybe because a single floating-point variable isn't precise enough?).

No, the reason file-based time estimate is not accurate is because the number of lines of G-code (hence file size) bears hardly any relationship whatsoever to the time taken to execute those lines. Consider that printing a 200mm X 200mm rectangle will take just 4 lines of G-code, while printing a 5mm circle could well take 50 lines of G-code. Using file size as a basis would mean that the small circle will be estimated to take over 10 times longer to print than the large rectangle, when obviously in reality the circle will print much faster than the rectangle.

Layer based estimates are only accurate if the object consists almost entirely of very similar layers. In practise a very large proportion of prints will have layer times that vary by large amounts. I have made prints where the layer times vary from under 20 seconds to over 20 minutes. The average filament feed rate is however reasonably constant throughout the print (though there are exceptions), and so gives the most accurate estimate - though the first layer is often printed far more slowly than the rest, resulting in the estimate being significantly pessimistic until the second layer is mostly complete. I've found however that I am able to make a reasonable guesstimate as to how long a print will take just by looking at the 3D model, which I suspect is true of everyone who has had a reasonable amount of experience with the printer.

Dave

Quote
dc42

Quote
appjaws1
David, did you ever check the feasibility of running a g-code file without printing to ascertain the expected print time?

I implemented that some time ago. See [reprap.org].

The link is not working. I do remember that M37 was the code to simulate a run but what I can't remember is if it ran in a reasonable time and if the result could be used in the web interface as a count down timer, which was one of the suggestions at the time. I am away from my printer at the moment so can't run M3 to see how it works.

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Quote
appjaws1

Quote
dc42

Quote
appjaws1
David, did you ever check the feasibility of running a g-code file without printing to ascertain the expected print time?

I implemented that some time ago. See [reprap.org].

The link is not working. I do remember that M37 was the code to simulate a run but what I can't remember is if it ran in a reasonable time and if the result could be used in the web interface as a count down timer, which was one of the suggestions at the time. I am away from my printer at the moment so can't run M3 to see how it works.

Correct link is RepRap.org