GCode viewer faster then actual print and print stops when viewer is at 100%

Get Help
1

What is the problem?

Octoprint gcode viewer is a bit faster (about twice as fast) then my printer is printing. Not a big issue for me.. But biggest issue is that when octoprint thinks the print is done; that my printer (Ender 3 v2) will stop printing. It will keep the nozzle and bed heated, and the screen of my printer is not reporting that it had been finished... it just hangs. my print is maybe halfway..

i have used octoprint for a while without issues; only this and the previous print got issues.. I did not noticed with the previous print what went wrong; i tought it had a power failure (but i guess that the issue was that octoprint was idle; and i had enabled to powerdown the PSU when so; already disabled that with my latest print).

anyone any clue where to look to solve this out-of-sync issue? (i guess that this will solve the issue that it stops printing mid-print).

What did you already try to solve it?

Not much, tried to disable some more plugins that i do not need. I am halfway of a big print, and trying to recover it. But it looks like my second half is still running to fast; so i think tomorrow i will end up with 75% printed... I could try to print the last part from SD; but file transfer is slow; and sd card is fysically not (easy) accessable.

Have you tried running in safe mode?

Yes; but i cant print, because i need the psu control plugin to power my printer.

Did running in safe mode solve the problem?

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)
octoprint-systeminfo-20240920222608.zip (114.5 KB)

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible
browser.user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36
connectivity.connection_check: 1.1.1.1:53
connectivity.connection_ok: True
connectivity.enabled: True
connectivity.online: True
connectivity.resolution_check: octoprint.org
connectivity.resolution_ok: True
env.hardware.cores: 4
env.hardware.freq: 1000.0
env.hardware.ram: 382251008
env.os.bits: 32
env.os.id: linux
env.os.platform: linux
env.plugins.pi_support.model: Raspberry Pi Zero 2 W Rev 1.0
env.plugins.pi_support.octopi_camera_stack: webcamd
env.plugins.pi_support.octopi_version: 0.18.0
env.plugins.pi_support.octopiuptodate_build: 0.18.0-1.8.6-20221018093204
env.plugins.pi_support.octopiuptodate_build_short: 2022.10.18.093204
env.plugins.pi_support.throttle_check_enabled: True
env.plugins.pi_support.throttle_check_functional: True
env.plugins.pi_support.throttle_state: 0x0
env.python.pip: 20.3.3
env.python.version: 3.7.3
env.python.virtualenv: True
octoprint.last_safe_mode.date: 2024-09-20T19:58:28Z
octoprint.last_safe_mode.reason: settings
octoprint.safe_mode: False
octoprint.version: 1.10.2
printer.firmware: Marlin bugfix-JyersUI v2.0.1 (Nov 5 2021 21:19:16)
systeminfo.generated: 2024-09-20T20:26:08Z
systeminfo.generator: zipapi

2

Hello @Doomic !

The gcode viewer is always faster than/ahead of the printer because of the printer's input buffer

3

thank you for the fast reply. Sounds right; but i don't talk about a little bit ahead; it is just faster.. so my 48hour print was reporting to be at 50% after 12hours; and after 24 hours it said that it was finished...
Sounds to me to be to extreme out off sync to be a buffer issue.

however. maybe you are right about my current situation; i start writing this help request because i saw it went faster again.. but when i now take a second look; i think that was because of the buffering.. It waits at the end of the layer to get (almost) back in sync.

Maybe it was indeed one of the plugins that i disabled before starting the recovery (using half of the gcode file). I guess that i have to wait till tomorrow to see if the issue still exists... I will report back.

4

I see.

Then I recommend

It estimates the print time by actual prints.
It takes some prints to run, but it quite exact then.

5

Thank you for the suggestion. I still don't think that octoprint would have stopped the print because estimated time was up; while there was a lot of gcode that was not send to the printer (assuming the printer does not buffer 40mb of gcode data).

However, the other 40mb of gcode was printing successful with the last run. So I guess there is a broken plugin.. now I need to figure out which one... But that is a task for another time.