[Poll] Time estimates on PanelDue 5"/7"
-
Since there are repeated and scattered requests to bring slicer time as an estimate to PanelDue and we only have limited space to show this information, I want to start a poll about opinions of what users want to see. Below you'll find a poll for larger-resolution screens of 5" and 7" PanelDue and a second for the smaller 4.3" variant here. I ask you to vote only for the screen you have or plan to get.
These polls will run until 2021-03-14. Each user has up to three votes.
-
Maybe clarify how these times are calculated?
- Layer time predicts based on previous layer times and the amount of remaining layers, right?
- File time looks at the remaining lines in the file and the average time to process a line?
- Filament time, no clue...
- Slicer time, magic probably,
- Simulated time; I see that for the first time to be honest
To me filament time is the "least meaningful" so I am going to vote that out
-
@wilriker Are we supposed to vote for a single item or multiple?
-
@nikscha said in [Poll] Time estimates on PanelDue 5"/7":
To me filament time is the "least meaningful" so I am going to vote that out
Out of layer time, file time and filament time, filament time tends to be the most accurate. I look at simulated time if available, otherwise filament time. Layer time is typically the least accurate, and I wouldn't miss it if it went.
Filament time looks at the total filament needed for the job (as reported by the slicer), the amount of filament consumed so far, and how long it took to consume that filament. It tends to over-estimate the time at the very start of the print because the first layer is usually printed at a lower speed.
The layer-based estimate is next to useless IMO.
-
To muddy the water could it possible to have a hierarchy of times:
"simulated time" is likely to be the most accurate - but only useful if the print has been simulated. If that's not available then slicer time (if the printer parameters are configured correctly in the slicer) is probably the second best bet. After that then filament/file time?
-
@T3P3Tony Basically everything is possible for up to three times. Hierarchies are no problem.
- Layer time uses the average of previous layers and applies it to the remaining amount of layers.
- File time just looks at bytes processed vs. remaining bytes (no lines/instructions, just pure file size)
- Filament time is based on what the slicer puts into the file as amount of required filament vs. amount of filament already extruded.
The above three are all calculated within RRF and provided to PanelDue
- Slicer time is what the slicer calculated it will take - this can vary wildly based on how accurate you can represent your printer configuration withing your slicer
- Simulated time is what RRF simulated (optionally) it will take - since this is accurately based on your settings this is the most accurate it can get.
The above tow are precalculated at some point in time and would simply be counted down. Main disadvantage is that they do no contain heating times and will be very inaccurate for very short jobs but this will even out for longer jobs.
-
Also worth mentioning is that when DAA or more general forms of input shaping are used, the slicer time will be less accurate, because the slicer doesn't know what input shaping your machine is using. Simulated time should continue to be accurate.
OTOH the slicer does know about things like the first layer being printed slower than the rest, and the last layers being printed slower if a minimum layer time is in effect. Filament-based time estimates take a while to catch up with print speed changes caused by those features.
-
While only 3 can be displayed at a time, if the "simulated" time is one of those included, the firmware should display an alternative time if/when the simulated time isn't available.
For example, it might display the slicer time when simulated isn't available, and some other time if neither simulated nor slicer times are available. That implies that parsing for all types of times is available in the firmware, so perhaps a better poll would be: What would be the priority order for displaying the times?
It might be important to note that the only time that is ALWAYS going to be available is the "file" estimate. The others all depend on RRF being able to parse certain information out of the gcode file (or a simulation having been run.)
-
@garyd9 said in [Poll] Time estimates on PanelDue 5"/7":
While only 3 can be displayed at a time, if the "simulated" time is one of those included, the firmware should display an alternative time if/when the simulated time isn't available.
For example, it might display the slicer time when simulated isn't available, and some other time if neither simulated nor slicer times are available.
I agree. if a simulated time is available then I'd like to see that. If not, then perhaps slicer time (if available) and filament-based time (which is nearly always available for 3D prints, but not of course for CNC jobs).
-
Adding my 2 cents, I would also prefer to see the slicer time if it is available. At least for all my machines that I use RRF/PanelDue on, the slicer time is and has always been more accurate than the others provided. I've never seen it off more than the warm-up time.
-
Why not make it configurable so we can choose whatever we want or feel works best for our printers?
e.g.., in
config.gintroduce a new M-code for PanelDue config:
M996 P"filament,layer,simulation"to set it, and a plainM996to retrieve the list of keys (which PanelDue needs to query during start-up). With the correct object model keys from https://github.com/Duet3D/PanelDueFirmware/blob/09397d29fd9c521c307b6a5679209b892d1c0a2a/src/PanelDue.cpp#L465-L467 -
@dc42 said in [Poll] Time estimates on PanelDue 5"/7":
Layer time is typically the least accurate, and I wouldn't miss it if it went.
Do we need more than one reasonable time estimation?
As for layer and filament consumption/progress, if needed, they can be reported in layer or meter units rather than translated to time unit.
-
Having more than one estimate is useful to me because the closer they agree, the more confidence I have in them. Also, if I have adjusted the speed during the print, then the slicer and simulation estimates will no longer be accurate.
-
Would anyone miss print time estimations based on layer times if I removed it? It's rarely accurate, the implementation is complex, and as slicers get more sophisticated (e.g. supporting variable layer height), it breaks more often.
-
I pay no attention to any of the estimates.
My "research" shows conclusively that the print will finish when it is done.
The only thing I watch is the current layer\total layers numbers.
Frederick
-
@wilriker Simulated time. Now if that would be added to the file in SBC mode would be great.
-
@dc42 said in [Poll] Time estimates on PanelDue 5"/7":
Would anyone miss print time estimations based on layer times if I removed it? It's rarely accurate, the implementation is complex, and as slicers get more sophisticated (e.g. supporting variable layer height), it breaks more often.
I sure wouldn't miss it.
My vote would be Simulated time if available, followed by Slicer time.
While we are here, why aren't actual print times stored after a print completes successfully? Why couldn't it be Actual/Simulated where either or populates the value?
-
@dc42 said in [Poll] Time estimates on PanelDue 5"/7":
Having more than one estimate is useful to me because the closer they agree, the more confidence I have in them.
On the other hand, when they don't agree, we need to guess which is is accurate, and question the duet for providing such an off the mark estimation.
Also, if I have adjusted the speed during the print, then the slicer and simulation estimates will no longer be accurate.
Can't this be done with the slicer info, since it provides a better linearization of the work time than file size or layer?
For example, the duet can start with providing actual estimated time and as the print progresses give higher weight to a (1 - fraction_done) * time_so_far style estimation where fraction_done is derived from the slicer's minute and percent markers.
Just a thought.
BTW, another interesting time estimation is to the next user event. If I define a pause at level x to perform an operation (e.g. inserting a captive magnet), the slicer also shows the time to that operation. I am not sure if it's propagated in the gcode.
-
@dc42 said in [Poll] Time estimates on PanelDue 5"/7":
Would anyone miss print time estimations based on layer times if I removed it? It's rarely accurate, the implementation is complex, and as slicers get more sophisticated (e.g. supporting variable layer height), it breaks more often.
I certainly would not miss the layer time estimate.
-
Taking account of the feedback so far, I propose to remove the estimate based on counting layers, and add an estimate based on the time that the slicer provided, supplemented by M73 commands in the file if they are present.
RRF will still provide a layer number in the OM for DWC and PanelDue to display, however it will be derived from comments inserted by the slicer instead of RRF trying to work it out from changes in Z height. So if the slicer doesn't provide layer comments that RRF recognises, then current layer number will not be available.
-
@wilriker said in [Poll] Time estimates on PanelDue 5"/7":
- Slicer time is what the slicer calculated it will take - this can vary wildly based on how accurate you can represent your printer configuration withing your slicer
That is quite right. For slicers like S3D its a huge problem, because you can't apply acceleration and jerk into the calculation of the time (not without post-processing). In my case, a file from S3D takes about 20-25% longer than estimated.
The most accurate for me is also the filament-time after a few layers (like DC42 explained), to tell when the print is finished./Julien
-
Layer time needs to go. It's useless if you have gcode set up in your slicer to move the z axis at the end of a print. Filament time is the most accurate so far.
-
We have removed the estimate from layer times in RRF 3.3beta2. It took up a significant amount of code space, didn't work at all in some cases, and was usually inaccurate even when it did work.
