On long prints using RC6 the hours are rolling back to zero. Not exactly sure when because it was an overnight job but I know I've done 13 hours OK. This was probably a 15 to 16 hour job, I don't know for sure. At the end it reported as 0 hours 36 minutes and I know for sure it wasn't 36 minutes.
WZ9V
All 27 comments
Hum.. this is on the LCD timer or the job info object (G78) ?
jbrazio
on 3 Jul 2016
On the XXL LCD.
WZ9V
on 3 Jul 2016
Do you have #define PRINTCOUNTER ? Is the total timer there correct ?
jbrazio
on 3 Jul 2016
Was printing from SD card with nothing connected so I can't check G78. I'll check the code and next time have OctoPrint connected.
I'll get back to you in 16+ hours, trying same print with OctoPrint connected this time.
WZ9V
on 3 Jul 2016
I searched configuration.h and configuration_adv.h and no #define PRINTCOUNTER
WZ9V
on 3 Jul 2016
In the RC-6 available July 1st 2016, there are these lines:
00811: //
00812: // This information can be viewed by the M78 command.
00813: //#define PRINTCOUNTER
00814:
Roxy-3D
on 3 Jul 2016
Not in the RC6 bundle I just downloaded from the releases page to be sure.
The RC6 bundle on the releases page is dated April 29th.
According to OctoPrint its a 21 hour job.
WZ9V
on 3 Jul 2016
My Mistake... I meant those lines are in the RCBugFix I looked at from July 1st 2016.
Sorry for the miscommunication.
Roxy-3D
on 4 Jul 2016
Please test with RCBugFix in case we already addressed this behavior. If we did, then we can close the issue. If the problem persists, we can look into solutions.
thinkyhead
on 4 Jul 2016
Print time is 18:48:31 according to OctoPrint. Hours were still displayed properly at 15 hours. I'll see what I can do with RCBugFix. This is a painful one to test since it requires a really long print.
WZ9V
on 4 Jul 2016
Actually we can do it without printing by using M75 to start the timer and M77 to stop it.
jbrazio
on 4 Jul 2016
I'll give the M75 a shot since I can't run another of that print due to needing to go back to work tomorrow.
WZ9V
on 4 Jul 2016
So far RCBugFix is not working for me. Lots of menu items missing in the version I grabbed around July 7th. I'll recheck when there is a RC7, I just can't keep up with the changes right now. Rolled back to RC6 to get printer going again.
WZ9V
on 11 Jul 2016
So far RCBugFix is not working for me. Lots of menu items missing
Which menu item do you need that is missing? We're making daily adjustments to refine the LCD items for About Printer, Print Stats, and static message screens (as with M600).
thinkyhead
on 11 Jul 2016
I can't say exactly but it looked like only about 1/3 of what was there in RC6.
In particular the entire print from SD Card section was missing. I might try using The one WheresWaldo posted on the Robo Community board. I may have missed something in the configuration when I did the setup.
WZ9V
on 11 Jul 2016
@WZ9V but even with the missing menu items, where you able to validate of the overflow is still there ?
We have two possible places for print timer overflow, one place is on the write to LCD routine, meaning only the display is overflowing but the internal timer is OK. The other one is within the internal timer.
Checking the current print stats with a M78and then starting a print timer with M75 when it overflows on the LCD we can check if it also overflowed on the internal timer by issuing again a M78.
jbrazio
on 11 Jul 2016
I'll reload the RCBugFix tonight and try the non-printing method you mentioned. I had some stuff I wanted to print, now that I have them printed I can give it another try.
WZ9V
on 11 Jul 2016
OK. Reloaded the RCBugFix code I had handy (7/7) I think. Hooked up an OctoPrint server and started timer with M75. Will check on it again tomorrow after work.
I can already see a difference, the display has 9 minutes where the M78 says 12 minutes.
WZ9V
on 12 Jul 2016
I can already see a difference
@WZ9V Get the latest code, because I believe #4258 addressed this.
thinkyhead
on 12 Jul 2016
Using the RCBugFix I had the problem is still there. At M78 saying 23 hours 38 minutes the display read 5 hours 22 minutes. I'll update to the latest RCBugFix tonight and try again.
WZ9V
on 13 Jul 2016
Using the commit 2b9515d and restarted test with M78 reading 23 hours 48 minutes. Wasn't sure how to reset the internal counter.
WZ9V
on 13 Jul 2016
A 16-bit integer counting seconds will overflow at 18:12:16 (which would be a good name for a movie). 23:38:00 minus 18:12:15 equals 5:25:45. Hmm.
4287 should address the problem.
thinkyhead
on 13 Jul 2016
I suspect that's it. I have it running with last nights code and I'll let you know when I get back to the printer tonight. I think the M78 differences are because I have no idea how to reset the internal counter so you are seeing the accumulated value from all of my attempts with RCBugFix. To answer the earlier question yes I'm talking about the print time displayed on the LCD. My really long print that uncovered this was well over 18 hours so the analysis above seems correct.
WZ9V
on 13 Jul 2016
I have no idea how to reset the internal counter
M78 S78
jbrazio
on 13 Jul 2016
RCBugFix did the same thing. The XXL LCD showed 6:00 and M78 is up to 48 hours from the prior 24 or so. The display still wrapped to 0 at 18+ hours using RCBugFix downloaded about 8PM yesterday.
The counter used by M78 seems fine it's only the write to the LCD that appears to have an issue with long 18+hour durations.
WZ9V
on 14 Jul 2016
This is indeed a bug with the internal timer.
It will be fixed by #4287 !
jbrazio
on 14 Jul 2016
RCBugFix did the same thing.
Allow stopwatch and printcounter to go over 18:12:15 #4287 [Open]
The green Open label above indicates that the PR hasn't been merged with RCBugFix yet. If you wanted to test that code you need to go to the PR, look at the top to see which fork and branch it comes from (thinkyhead:rc_long_print_times), and download the code from that branch.
thinkyhead
on 14 Jul 2016
Related issues
ahsnuet09
路
3Comments
Tamonir
路
3Comments
Kaibob2
路
4Comments
Anion-anion
路
3Comments
spanner888
路
4Comments