[Poll] Time estimates on PanelDue 5"/7"

dc42

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.

fcwilt

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

Stephen6309

@wilriker Simulated time. Now if that would be added to the file in SBC mode would be great.

oozeBot

@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?

zapta

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

garyd9

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

dc42

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.

ZipZap

@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

Surgikill

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.

dc42

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.