Simulation and print time estimates
-
As I understand it, the new 2.0 firmware appends the simulation run time to the Gcode file.
What is the best way to view this information at a later time?
Is it right clicking on the gcode file and selecting edit in order to view the appended information?
I don't see anywhere in the DWC where it is displayed.Further, how does a simulation run effect the time remaining estimates displayed for file length, filament, and layer time? Do they become more accurate?
-
@phaedrux said in Simulation and print time estimates:
As I understand it, the new 2.0 firmware appends the simulation run time to the Gcode file.
What is the best way to view this information at a later time?
Is it right clicking on the gcode file and selecting edit in order to view the appended information?This is one possibility. You could also download the file and open it in any editor.
I don't see anywhere in the DWC where it is displayed.
DWC does not, at present, read or display this information. Considering that it would have to read every file, and some of them could be quite large, it seems unlikely that it ever will.
Further, how does a simulation run effect the time remaining estimates displayed for file length, filament, and layer time? Do they become more accurate?
No. These numbers are calculated by the firmware in real time, and reported in rr_status so that DWC (or anything else) can display them. The three are exactly what they say: File Length in bytes vs. how much has currently printed, Filament needed vs. how much has currently printed, layers vs. how many have printed , each of the three multiplied or divided by how much time has already elapsed since the print started.
Note that the firmware sort of does and sort of doesn't scan the entire file to find any of these three totals. "Does" in that it scans for comments placed by the slicer... "Doesn't" in that it doesn't parse every bit of the G-Code to get these totals.
Total bytes comes from the file system directory entry. Total filament and total layers come from comments placed by popular slicers. If these comments are not present, the firmware cannot (does not) report those estimates.
-
Further, if the comments are 'wrong', meaning they don't match the file, the estimates can be quite wacky.
The other day, I restarted a file that had physically run out of filament after 30 something hours of print. I restarted by deleting all the G-Code between the beginning of the (large) file and the last layer that actually printed. The comments at the beginning were intact... and therefore the printer reported something way off on a couple of the estimates.
I don't remember exactly, but something like the layer estimate said 9 hours remaining (which was roughly correct), but the bytes or the filament or both said thousands of hours... so far off it was easy to see they were wrong.
-
And, last, let's assume we try to use simulated time in the maths.
The things the firmware "knows" as the print progresses are total filament vs. current filament, etc. and the time elapsed since start of print.
If we develop a fraction from total and current, and use that fraction to estimate time, we could use the "time since start of print"... or... we could use the "Estimated time" minus the "Time since start of print".
Using actual time alone means the calculation will get better and better as the print progresses. Using the estimated time means it will get worse and worse, with the extreme case being those moments when the actual time has become greater than the estimated time. What do you do then?
-
Thanks for the replies. I guess it would help me to know how the simulation actually works and arrives at its time. I figured that since it was appended to the file it would display somewhere in the DWC. It manages to grab the layer height from the start of the file, as well as the slicer identifier string.
-
The simulation that runs in the Duets from what I understand is a print process with all of the 'delays' logged and the output skipped. The build time estimation is the sum of these delays and is accurate other than any warm up or temp change time.
Where I say delay it may be a little missleading. The duet is unlikely to ever block on an internal wait for x seconds command like you see in Arduino coding examples, it will be effectively mark up something to be done at or after a specific time and check if it is due on each cycle.
Think the DWC is largely a client side website with most of the processing done on the remote device. If so as others have said the remote computers would have to download the last few bytes of the file to display the time. It would probably work much smoother if there was a gcode command to get the duet to report a previously simulated time. Without a checksum though there is little guarantee the file hasn't been changed since the simulation.
-
@phaedrux said in Simulation and print time estimates:
As I understand it, the new 2.0 firmware appends the simulation run time to the Gcode file.
What is the best way to view this information at a later time?The latest PanelDue firmware displays the simulated print time if it is available, otherwise the estimated (by the slicer) print time if it is available.
Is it right clicking on the gcode file and selecting edit in order to view the appended information?
I don't see anywhere in the DWC where it is displayed.DWC does not yet display these times.
Further, how does a simulation run effect the time remaining estimates displayed for file length, filament, and layer time? Do they become more accurate?
The simulated time info is not yet used to modify the estimated print completion times.
-
That's good to know. I haven't started a print from the PanelDue yet. I'll keep an eye out for that.
