Estimating print end time

I'm looking for the best way to estimate print end time in the web interface. My latest variant of Matt's web interface (0.74) in conjunction with firmware 059-dc42 provides four estimates (the three that Mat implemented and one that I added), which are based on the following:

1. Number of layers remaining, based on the time take to complete the last layer;

2. Number of layers remaining, based on the time taken to complete all the layers printed so far;

3. Number of layers remaining, based on the time taken to complete the last 5 layers;

4. Amount of filament still to be extruded, based on the average rate at which filament has been extruded so far. This is the one I added, after someone suggested it - sorry, I can't remember who it was.

What I am finding is that the last one of the four gives the most consistently reliable estimate. However, I would like to improve the accuracy further. Does anyone have any suggestions? Here are some possibilities:

* Work on the amount of filament still to be extruded, but use the average rate of extrusion of the last N layers instead of all layers so far, and/or omit the first M layers from the calculation (for some M and/or N). In particular, this allows for the fact that the first layer is typically extruded at a lower rate than the remainder.

* Can slic3r and/or Cura be configured to add a comment at the end giving the estimated print time? slic3r has a number of variables that can be inserted in comments, but I can't find any documentation for them, and I haven't looked at the source code yet. If they can give an estimated end time, what is the best way to fine-tune that end time as the print progresses?

* Something completely different?

Suggestions welcome!

---

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

David,
I agree that the filament calculations at the moment provide the most accurate time estimate. The real problem is that each layer has so many variables applied that unless a time for each layer can be worked out based on filament used and print speed, it will be impossible to be 100% accurate.

Probably the nearest we could get is the amount of filament remaining, divided by the number of layers remaining, multiplied by the average print time of the last 3,4 or 5 layers.

I wonder if slic3r can report the estimated filament for each layer in the gcode file and if that information can be used during the print. This would involve a lot of calculations and space so I'm not sure if it would be feasible

just my 2p worth

Paul

---

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

It's a real difficult puzzle that David... Take a Cone pointing upwards, and by using the layers already done in a calculation it's going to make it guess a longer time than it would be... A cone pointing downwards would always tell you to shorter time... I think the only way to solve it is to have it read the file, and that's going to use up all your memory I think, and be a slow old job... Maybe just the amount of filament used to a point, and how much there is still left to be used. Slic3r has a total Filament figure....
As for the time to finish, just use the last layer done, rather than the last 5, as the cone examples would make them massively wrong. But a last layer would still be out, but it's closer...


Thank you very much for your help, and pointing out the messed up config file here....
It was in a worst state than that, but I missed a few things.
At least it explains the reasons for the problems running the Firmware...

---

Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete

I have just taken a dive through the Slic3r v1.0.1 source code. Even though it keeps track of the elapsed time and filament used, it does not expose any of that information through the placeholder variables. Almost all the variables are static config information, the only changing variables are the layer index for the "Layer change G-code", the next/prev tool indices for the "Tool change G-code" and updating the current time (unrelated to print time). You can't even access the total filament used.

I have attached a file with the list of placeholder variables that I found to be available.

Another option I can think of is to integrate one of the javascript G-code analyzers/viewers and glean the information from it. In particular, gCodeViewer at gcode.ws (github.com) seems to have very clear separation between it's analysis, UI, and 2D/3D rendering portions. I think it reduces down to just analysis functions if you use only those files (which I suppose could then be packed into a single file), and can then be controlled/queried through javascript. Or it could be included in full to provide a G-code viewer tab.

gCodeViewer seemed to have fairly accurate time estimation the one one time that I paid attention to that (not including waiting for temperatures). I'll do some testing of it's timing and see if I can isolate the analysis portion.

-Ross

Edited 2 time(s). Last edit at 05/10/2014 03:49AM by RossC.

Ross, thanks for looking at the slic3r source code. It's a shame there are not some more useful variables.

Integrating javascript gcode analysis code might be straightforward for direct web print, but I find that unsatisfactory because the data can't always keep up with the printer. So I'm looking for something that work off the data already on the SD card. I guess one possibility would be for the upload mechanism to first analyse the gcode, and then tack some extra comments on the start or the end of the file being uploaded. So as long as you uploaded to the SD card through the web interface, the data would already be in the file.

---

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

I agree it would be the best way to parse the g code while uploading, but you would have to incorporate the acceleration values to make the estimation somewhat accurate. Another option would be to estimate the time left based on the current line in the g code, e.g. by making M110 echo the current line number. Doesn't Pronterface report the current progress this way when printing over USB?

zpl, that suggestion sounds good to me. Rather the echo the current line number, I think it will be easier for the web comms to report what proportion of the file has been processed. We know the file size, but not the number of lines in the file unless we count them.

---

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