New firmware 0.96a and web interface 1.05

My print that simplify3d reported as build time 90.99 mins (1.52hr) - 1hr 30mins actually took 2hr 7mins. so that program is not very accurate.

---

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
jstck
In theory it should be possible to give a very accurate estimate of the print time, if you have the gcode, any in-printer settings (such as firmware limits on speed and acceleration), and estimates of any "wait for warm-up" commands (which generally only happen once at the very start). If you go through each move and calculate how long it will take and sum that up, how far does that really differ from actual print time, and if it does, what is causing it? Such a calculation might be possible to churn through in printer firmware, but I'm not sure how useful that possible extra precision is really worth to me. In all honesty, not very. The current estimates (with their flaws) have always been sufficient for my needs at least.

Well yes, but it is a non-trivial calculation due to the fact that the time that each move will take must take the acceleration, commanded speed and maximum speed into account, using the same algorithm as the printer uses. Does the printer apply the acceleration to the X and Y moves (whichever is the limiting axis), or for the vectored move, for example. I don't know which method the Duet firmware adopts (it only needs to apply it per axis rather than on the vector, but does it?) It would even be possible for the firmware to implement a different acceleration for the X axis than the Y axis (and different again for E and Z). The X axis, being lighter, can probably withstand a greater acceleration than the Y axis. I suspect that DC42 will implement that one day!

It also means doing a "dry run" by reading the entire g-code file before starting the print, which could potentially take several minutes (though such "priming" could be done under user control).

Meanwhile, once it is past the first layer, using the rate of filament consumption will probably give the most accurate estimation for the majority of prints because that is likely to be more constant than either layer time or number of lines of code executed per unit time. The exception is going to be where the layer characteristics changes significantly part-way through the print, and has (for example) a significantly different number of non-printing moves or filament retractions per unit time - or if there are significant changes of average print speed caused by small perimeters etc.

Dave

Dave, thanks for taking the trouble to write that, I agree entirely.

The only simple way I can think of to improve the estimate near the start of the print is to take account of the first layer being printed more slowly than others when calculating the expected rate of future filament consumption. This would allow a better estimate to be generated once the first layer is complete. Alternatively, once a reasonable amount of filament has been extruded in the second layer, ignore the first layer figures when calculating the filament consumption rate. My version of the web interface calculates the rate from the last 5 layers (or all layers if less than 5 have been completed), so the slower first layer speed distorts the estimate until 6 layers have been completed.

---

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

Yep Dave, I couldn't explain it better Estimating the print time this way may seem trivial, but there are lots of factors you need to take care of, and the power of the SAM3X as well as the IO bandwidth of the SD card is limited. I guess that's why nobody has implemented this feature yet.

And Dave, to answer your question: The firmware applies only one acceleration to each move, although I guess it would be ideal to use individual accelerations per drive. If I get time, I'll have a look at the Move code again and check if I'm able to implement this.

dc42, out of curiosity, how are you planning to implement your bowden-tube elasticity compensation? Am I right thinking it will be necessary to implement exactly this feature to gain more control over the extruder drives? I'm really looking forward to a seeing a working implementation, because it has potential to improve print quality at higher printing speeds. At the moment I still get small bulges at sharp corners, and I'd like to get rid of them sometime soon. If I can help you, please let me know.

Quote
appjaws1
My print that simplify3d reported as build time 90.99 mins (1.52hr) - 1hr 30mins actually took 2hr 7mins. so that program is not very accurate.

Thanks for testing! So it turns out using these times won't be an option - less work for me.

Quote
dmould
It also means doing a "dry run" by reading the entire g-code file before starting the print, which could potentially take several minutes (though such "priming" could be done under user control).

The Duet CPU is pretty snappy, I would guess it could churn through a typical 2MB/100k-line file in just a few seconds (and possibly be limited by the SD card speed). It has to run through the same look-ahead move planner algorithm as the firmware already does to be really accurate, but maybe it's possible to reuse/modify that code to just "calculate" moves instead of actually moving. Not entirely trivial, but maybe not significantly harder than doing clever heuristics to combine various other kinds of estimates.


The estimate based on filament consumption is the one that usually seems most accurate to me, but it can vary quite a bit in some prints. Especially those that have lots of fast infill or simple perimeters at some heights and mostly just slower perimeters at others (such as things with a large simple "base" and small detailed things on top, where it can greatly underestimate the time to completion).

Quote
jstck

Quote
dmould
It also means doing a "dry run" by reading the entire g-code file before starting the print, which could potentially take several minutes (though such "priming" could be done under user control).

The Duet CPU is pretty snappy, I would guess it could churn through a typical 2MB/100k-line file in just a few seconds (and possibly be limited by the SD card speed.

I was thinking that the calculations would be done in the web interface rather than the Duet, and going by the length of time a file takes to upload rather than the time required by the calculations. If the Duet firmware does it, then it could work on each new file in background and store the result in the file at the end.

Dave

The web interface doesn't have enough knowledge of the machine to do the calculation without more information being passed back, and it would be necessary to download the file. Running a simulation on the Duet would be possible although I don't know how long it would take. The heating times would have to be estimated.

---

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 have been doing some calculations on a spreadsheet, taking each movement and the speed of that movement and working out the time taken. So for each X, Y, Z and E entry in the gcode file, worked out the distance from the previous movement then multiplied by the "F" entry converted to mm/sec. Totalled all of the resulting times to give the actual print time in seconds. While I was doing this, as a check that I actioned all gcode lines, I also summed the E values which agreed with the reported filament used.

Now I know this will not be 100% accurate because of machine specific parameters like acceleration etc. but I think it will give a very good idea of the print time at the start or even before the start of the print as a result of processing the gcode on file load to the duet or sd card.

The file I used was just a very small 100x2x2 cube and the actual print time was very close to the predicted time on the spreadsheet, within errors caused by starting and stopping the stopwatch. I need to run a large file as a check.

I had to construct the spreadsheet manually, which was very time consuming, I could do with a script that I could run against a larger, more complicated gcode file so the concept can be proved or disproved.

I wish I could program then if this concept is a load of rubbish, I would not have bothered anybody.

Any offers of a script?

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

Doesn't Pronterface estimate the print time when loading gcode files? Has anyone compared its estimation with actual printing times yet?