total print time ( again )

[morgan-it]

Nice Feature Request:
should be nice to have a counter for total print hours of a printer, it should be displayed in lcd or on serial via an Mcode
i do not think is too difficult, and i think could be very useful

[AnHardt]

@morgan-it
What is your definition of print time?
First activity - last activity?
Switching the power off is a bad choice for the last activity - no power to write the value away..

[daid]

https://github.com/Ultimaker/Ultimaker2Marlin/blob/master/Marlin/lifetime_stats.cpp
Just leaving this here.

[morgan-it]

i mean:
@AnHardt
how many days, hours, minutes, seconds of printing time has my printer
@daid
Daid i think you you are right

[morgan-it]

Daid i have tried to compile ultimaker2marlin firmware but gives me some error

[schirrel]

Sorry to reopen it after a long time. But has it been managed?

[thinkyhead]

Before I evaluate this concept I need to understand better:

• How many write cycles can the EEPROM handle before it fails?
• Can writing to one "cel" in the EEPROM affect the lifetime of other "cels" in the EEPROM?
• Is this even something I should concern myself with?

[daid]

@thinkyhead see the link I posted. As I've implemented this for the Ultimaker2, and did the checks and math on it.

[jbrazio]

I can't understand why this is so demanded.. but ok it won't hurt adding it to our feature list.

@daid do you know if only the offset being bytes written degrades or all the EEPROM space degrade at the same pace ? I can see the print counter accumulator to be written much more than once an hour.

And I can also see the angry mob with torches and pitch forks the next time we upgrade the EEPROM layout.. as this may become become a "pride token" among the users.

[daid]

@jbrazio the EEPROM degrades per byte.

[bobc]

I did some EEPROM life tests for work. We use a conservative figure of not more than 1 write per hour to stay within 100,000 cycles over a 10 year life. We just write the EEPROM on an hourly timer.

In destructive tests, I got to several million cycles before EEPROM started to show wear, but that was only one sample under particular conditions (voltage/temperature).

I guess if you do once per hour, or after "end of print" (maybe 15 minutes inactivity?) that should be fine for at least 5 year life. If the EEPROM does wear, you just get bad results from the worn bytes. The rest still reads ok.

To avoid losing hours, I suggest a "flush" command that can be use at end of print. Otherwise, if the user prints for 50 minutes and powers off every time, no hours get recorded.

That is pretty much the best you can do with standard EEPROM, without going to FRAM or a large NOR Flash.

[jbrazio]

Thanks for the insightful comment.

[schirrel]

@daid @thinkyhead @jbrazio i just asked it because i was looking the gcode file that Cure makes to sd and i saw that it has a line which is writen the time of the print, and rather than making math wouldn't be better to just use this variable?

[jbrazio]

Could you post the gcode ?

[schirrel]

The machine setting was a mender, and this gcode i've made just for test. For look what was inside.

M190 S70.000000
M109 S195.000000
;Sliced at: Sat 23-04-2016 16:46:59
;Basic settings: Layer height: 0.15 Walls: 0.8 Fill: 20
;Print time: 6 minutes
;Filament used: 0.266m 0.0g
;Filament cost: None
;M190 S70 ;Uncomment to add your own bed temperature line
;M109 S195 ;Uncomment to add your own temperature line
G21        ;metric values
G90        ;absolute positioning
M82        ;set extruder to absolute mode
M107       ;start with the fan off
G28 X0 Y0  ;move X/Y to min endstops
G28 Z0     ;move Z to min endstops
G29;
G1 Z15.0 F9000 ;move the platform down 15mm
G92 E0                  ;zero the extruded length
G1 F200 E3              ;extrude 3mm of feed stock
G92 E0                  ;zero the extruded length again
G1 F9000
;Put printing message on LCD screen
M117 Printing...

;Layer count: 79
;LAYER:0
M107
;LAYER:1
M106 S127
;LAYER:2
M106 S255
G1 F2400 E-1.00000
G0 F9000 X88.311 Y97.323 Z0.600
;TYPE:WALL-INNER
G1 F2400 E0.00000
G1 F1020 X88.611 Y97.321 E0.00748
G1 X88.611 Y98.416 E0.03480
G1 X88.311 Y98.417 E0.04228
G1 X88.311 Y97.323 E0.06957

After this was the rest of the gcodes printing, i don't thinks is necessary in this case

[jbrazio]

You speak about the "print time" comment ? That's not accurate, it's what the slicer thinks it will take.

This is an easy implementation, we are just concerned with the EEPROM durability in the micro controller as it has a limited write cycle count. But has explained before we should be ok with it.

[schirrel]

@jbrazio yeah i know that its not accurate, its only estimated, and as you guys was worried about it thougth it was a good way. Well at least i have never have too much delay from the real print time to the one the slicer provides. So maybe is better to give to the user an estimate of the time, than calculate it or used eeprom or anything else. But i know it is a bad practice.

[thinkyhead]

@jbrazio This would be independent of the EEPROM layout. We would store total time info either before EEPROM index 100 (that range is unused currently) or at the very top of the EEPROM. That allows us to change the rest of the layout as-needed.

@daid Thanks for the link. I will check it out. Douglas Adams came into my brain for some reason…

“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked
  filing cabinet stuck in a disused lavatory with a sign on the door saying
  ‘Beware of the Leopard.”

[jbrazio]

This has been implemented in PR #3625

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.