🚧 PFW-1206:Inital M75-M78

[3d-gussner]

Initial M75-M78 gcode and update PL/HOST print statistics
In Octoprint Settings GCODE
Add M75 in start
Add M76 in pause
Add M75 in resume
Add M77 in stop

Known issue:
Sometimes after a longer USB print PAUSE the total print time completely wrong.
@gudnimg Can you please have a look?

[github-actions]

All values in bytes. Δ Delta to base

Target	ΔFlash	ΔSRAM	Used Flash	Used SRAM	Free Flash	Free SRAM
MK3S_MULTILANG	734	0	246866	5633	7086	2559
MK3_MULTILANG	732	0	246150	5642	7802	2550

[gudnimg]

I think || here should be && otherwise pause_time is always 0

When I run M75 when resuming a paused print, then pause_time is never given a value.

[gudnimg]

And ofcourse pause_time = 0 should be pause_time == 0 :)

[gudnimg]

Overflow issue

@3d-gussner I believe the overflow issue comes from running M75 with M602 on resuming a print.

M75  // Start/Resume the print job timer
M602 // Resume print

pause_time += (_millis() - start_pause_print); is run twice. Once in M75 and once in M602.

We cannot rely on checking if pause_time == 0 in M75 because pause_time is accumulative. If you pause the print for example twice, then on the 2nd pause, pause_time != 0

Steps to reproduce:

Octoprint GCODE Scripts setup

Before print job starts

M75 ; Start/Resume the print job timer

After print job completes

M77 ; Stop the print job timer

After print job is cancelled

M77 ; Stop the print job timer
M84 ; disable motors
M106 S0

After print job is paused

M76  ; Pause the print job timer
M601 ; Pause print

Before print job is resumed

M75  ; Start/Resume the print job timer
M602 ; Resume print

Steps to reproduce:

1. Connect to the printer via Octoprint (I use octoprint serve in the command line and open http://localhost:5000/#term)
2. Start a USB print
3. Once the purge line is extruded, go to the LCD -> Statistics.
4. Note the time on the LCD, and pause the print via Octoprint.
5. Let the printer stay paused for at least longer time than noted in previous step. For example if the LCD showed 3 minutes, then wait for 4 minutes before resuming the print.
6. Resume the print via Octoprint
7. Go to LCD -> Statistics again immediately
8. Once the nozzle has been reheated, and the extruder is unparked and starts printing => notice the issue (the time changes abruptly).

ℹ️ there is no need to finish the print to reproduce this. One just needs to wait for longer time than whatever the print time was when it was paused. In the logs you will see pause_time is incremented twice! It is only when it it larger than _millis() that we see overflow but that is only a side effect of the real issue.

---

A bit off topic - I looked a bit at Marlin 2.1

I looked into how Marlin 2.1 is counting the print time, and it looks like to me they do not take into account how long the print has been paused. So the "paused time" seems to Prusa specific 🤔

I think we can simplify this somehow with the "print states" @3d-gussner talked about. We should only run pause_time += (_millis() - start_pause_print); if the print state is changing from PAUSED to RUNNING.

What is the best approach to solving this? I'm honestly not sure right now and will think on it over the next week.

For what it's worth I -- just for fun, and curiosity -- tried implementing Marlin 2.1's stopwatch.cpp code, but faced one issue due to the fact Marlin 2.1 completely ignores the paused duration from what I could tell. I have a working code, but it uses only slightly less memory ~40 bytes which is not that significant.

Here are my code changes if you're curious gudnimg@66d4823 :) It was mainly just for fun and see if it uses less memory.

⚠️ I didn't finish changing Stopwatch::duration() so the pause time calculation is not correct at the moment. I was trying to find ways to minimize flash consumption.

[3d-gussner]

Closing in favor of #4493