Marlin: Display time remaining on the LCD screen ?

Created on 28 May 2015 · 17Comments · Source: MarlinFirmware/Marlin

How to display on the LCD screen printing time remaining and not the elapsed time ?

FYI : If I print to USB I can see the time remaining but live via SD card I see nothing

Thx

Source

starzleo

Most helpful comment

actually Cura does : you can add your acceleration and jerk settings

for a print which takes 10 hours, the error of the estimation is only few minutes.
And with my calcul, the time converges to 0, and I know it's only an estimation.

An other impruvement will be to solve the "non linear" percentDone value : it is an estimation calculated with the number of line of code, but each line doesnt take the same time.

I added my code in all my Marlin firmware and I find it usefull, if other people want it, let me know (or maybe open a new branch, but i will need help for that, I never did that before...)

spilz87 on 1 Aug 2017

👍2

All 17 comments

this is send by the host. We can't estimate the time, because we don't parse the complete file before printing.

Wurstnase on 28 May 2015

Ok , thank you

starzleo on 28 May 2015

@Wurstnase If the slicer include a command in the g-code file, like % printed, is it possible to calculate (estimate) the remaining time?

clefranc on 28 May 2015

We already have the "Progress bar" and the print-time on the display.
It works based on the file-length and gives at least a rough guess.
(3 hours gone, 1/4 left = 1 hour left)

AnHardt on 28 May 2015

The slicer could place the total time at the start of the file in an M
code. Then it would be easy for Marlin to give an accurate time remaining.
Of course the slicer would need to know the firmware speed and
accelerations but the host is in the same position.

On 28 May 2015 at 20:25, AnHardt [email protected] wrote:

We already have the "Progress bar" and the print-time on the display.
It works based on the file-length and gives at least a rough guess.
(3 hours gone, 1/4 left = 1 hour left)

—
Reply to this email directly or view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/2181#issuecomment-106572076
.

nophead on 29 May 2015

It would be very nice to enhance progress bar by calculation estimated time remaining. It does not make sense to "force" user to estimate how much is printed based on the progress bar and then calculate manually from "time from start". Reasonable SW should do this job for the user and scuh calculation would not ruin performance....

walterX12 on 4 Mar 2017

@walterX12
As soon you will provide a __reasonable__ algorithm to calculate the time without reading the complete file before I'll implement it. The progress bar is based on filesize and already printed bytes - has only a very rough relation to the __time__.
Having no number is better than a wrong one.

Blue-Marlin on 4 Mar 2017

It is much better to use the same estimation as used on progress bar to
display time remaining, then t leave it up to the users.
For example if progress bar shows 1/10 progress and print was started 1
hour ago. It wuould calculate for user that time remaining is: 9 hours

2017-03-04 20:40 GMT+01:00 Makaira notifications@github.com:

@walterX12 https://github.com/walterX12
As soon you will provide a reasonable algorithm to calculate the time
without reading the complete file before I'll implement it. The progress
bar is based on filesize and already printed bytes - has only a rough
relation to the time.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/2181#issuecomment-284175694,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AY8EQdfGqCXhBRi4i5iFzJP7NlZHxxeWks5rib4mgaJpZM4EtXUb
.

walterX12 on 4 Mar 2017

So, roughly…

remaining_time = (elapsed_time * file_size / file_done) - elapsed_time;

thinkyhead on 6 Mar 2017

hello,
Display time remaining is important for me, so I added some code to Marlin to calculate it and display it instead of the time elapsed.

I agree with you blue_marlin, having no number is better than a wrong one, but if I know it could not be the good one, and if I know the error is not so big, i prefer to have the value.

How I did that :

Cura slicer put the total time on the top of the file
I modifiy the code where file is read on SD card (Marlin_main.cpp / #if ENABLED(SDSUPPORT) ) to read the comment lines and find the total time value calculated by cura (according it's not to bad)
Added a function in cardreader.h to have a better value of percentDone (1/10000 instead of 1/100)
In display code I estimate remaining time by : remainingTime = totalTime * (1-percentDone)

I agree it's not perfect, it's not exactly linear, but it converges, and it's ok for me

An impruvement is to use "TIME_ELAPSED" value provided by CURA at each layer to attenuate the "non linear" percentDone calcul.

Sorry for my bad English

if people have other suggestion, i will be happy to try their

spilz87 on 31 Jul 2017

The problem is that cura doesn't know about your acceleration and jerk settings so it can only perform educated guesses about how much time has elapsed.

Thats why more sophisticated calculators (such as G-Code Analyzer) ask you to provie your acceleration and jerk settings.

FHeilmann on 31 Jul 2017

actually Cura does : you can add your acceleration and jerk settings

for a print which takes 10 hours, the error of the estimation is only few minutes.
And with my calcul, the time converges to 0, and I know it's only an estimation.

An other impruvement will be to solve the "non linear" percentDone value : it is an estimation calculated with the number of line of code, but each line doesnt take the same time.

I added my code in all my Marlin firmware and I find it usefull, if other people want it, let me know (or maybe open a new branch, but i will need help for that, I never did that before...)

spilz87 on 1 Aug 2017

👍2

@spilz87 Can you please share your modified files, so I can add it to my firmware?

sergioandyp on 13 Oct 2017

👍1

Distinguish between a 100.000% accurate remaining time estimate and a useful remaining time estimate. I would appreciate a useful remaining time estimate.