I also see this same behavior. To give more description I notice that GCODE viewing (and percent done) lag EXACTLY some number of draw steps behind the printer. That is to say, each time a line draw happens on the ender, a line draw happens in gcode, but the gcode is perhaps 100 moves behind.
THis is with the latest Octoprint that I allowed to update 2 days ago.
I have this issue too, when using 1.3.12, it goes around 5 move faster than the printer, but when running 1.4, it goes at least a layer behind the printer.
I too have observed this behaviour since the 1.4.0 upgrade - the gcode viewer appears to 'lag' well behind the actual print. Previously it was a few steps ahead....
So it seems it is a real thing - not just on my setup. The reason why I didn't report it as a bug when running the RC's for 1.4 was that nobody else was experiencing the same issue - and it isn't affecting performance or output.
I have looked at the "standard" log files on the Pi and I can't see any errors or problems. Does anyone know any debug logging I could switch on for the gcode viewer to try and see what is going on?
John
I noticed this issue as soon as I updated to 1.4.0. I watched a print complete, on the G-code viewer page, and it was at least four layers behind (still showing infill and no upper shell) when the print completed.
I posted this a few days ago, but +1. would love to find a solution
There are other posts cropping up with similar issues - like this one:
once more 1-4 does something bad gcode viewer wont work
I am about to try a different slicer, and I will see if I can hook my Pi up via cable rather than wifi. I don't think that will fix it but just trying to eliminate possibilities.
I've not seen that on my own instances so we need more data. Let's do a bit of a roll call.
- Slicer (name and version)
- printer make and model
- firmware on printer (name & version)
- approximate delay in seconds
- underlying OctoPrint server hardware and network connection (wired vs wireless)
- reproducible in safe mode? If not, installed third party plugins
Chiming in to say I am having the same problem with my setup. Pi 3B+ with wireless connection. The visualization and the estimated time remaining lag significantly the longer the print.
Thanks
Hi Foosel! My data:
- Cura V4.4.1
- Ender 3 with an MKS Gen L controller V1.0
- Marlin V1.1.9
- The delay worsens over time. So it will be in sync at the start then maybe say 5 seconds at the end of the 1st layer. Then 10 seconds at the end of the second layer etc.
- Raspi 3B+, Wireless connect, Octopi 0.15.1
- Confirm same behaviour when running in safe mode.
I will report back when I have tried PrusaSlicer and connected via ethernet.
Also if there are any settings to change to get potentially useful log files let me know and I will do all I can to help
Sorry for not reading the post directly above mine.
Slicer is Cura 4.4.1
Printer is Ender 3 Pro
New Upgrade Silent Mainboard V1.1.5 with Creality Firmware 1.1.8
At 28 minutes in the delay is already about 40 seconds, but that will increase.
Octoprint is on a Raspberry Pi 3B+ viewing wirelessly from a Windows 10 Laptop through Chrome at the printer's IP address.
Have not tried in safe mode, will need to research that.
3rd Party Plugins: Automatic Shutdown Version 0.1.4, Navbar Temperature Plugin .11, Polar Cloud 1.9
Hope this helps!
Edit: My print time is accurate under state, but the estimated print time remaining gets wildly off towards the end of the print where it used to dial in and get more accurate as the print went along.
Hi,
after the Upgrade from 1.3.2 to 1.4 the Gcode Viewer isnt working anymore. After refreshing the webside it works for a few seconds till it gets slower and stop at some Point.
I dont need any help to fix it because its nothing nessesary but i think its a bug with the new version and i just want to let you know 
It seems similar to my "curious issue" but worse. Acce75, what are you running Octoprint on? Mine is a Pi 3B+, if yours is a less capable processor it might explain why yours is worse.
OutsourcedGuru - any thoughts on tweaking settings to get some logs and try to see what's going on?
Usually in a case like this you look for any feature changes that were added in the major revision and I note that foosel was in there working on this part at some point.
In reviewing the release notes, though, it doesn't look like anything significant changed in this part itself.
yes your linked Problem it is.
i printed a 1 Hour Print yesterday, so i didnt notice that much lagg behind.
Today im at a 5Hours print and you can clearly see a big lag on the "time" and gecode.
i use a Raspi 3B via Wireless.
Just want to confirm that I am seeing the same issue. Pi 3B+ with wireless connection. Not a huge issue since I don't sit and watch the screen for an entire print, but it is nice for a time estimation, which also lags significantly along with the visualization.
Thanks
I merged a duplicate thread into this one, all of the new comers (and those of you who haven't yet participated in the roll call), please share some data per this post:
Also just to confirm, the print progress in the sidebar under state, is it lading for everyone? Because if so it's a case of the status updates not being pushed in time over the socket, not just the gcode viewer being affected.
1 Like
- Cura 4.5.0
- Ender 3 Pro with BL-Touch
- Marlin 1.1.9
- 'Lag' increases over time, but estimated to be 3min after 30 min printing
- Octoprint 1.4.0 on RPi 3B/Wifi
Note: Before Octoprint 1.4.0 upgrade, the printer was slightly behind the Gcode viewer - but understandably due to buffer etc.
This just gets weirder. I have a test print which is just a 3 layer credit card sized plate. Useful for seeing any delays without waiting too long.
If I print the gcode created by Cura it takes 26m10s to complete the print. The live gcode viewer lags by about 3 seconds per layer so it is about 9 seconds delayed by the time it finishes. As the print finishes the "Printed" value in the State section shows 91% then jumps to 100%
If I slice the same model with PrusaSlicer V 2.1.1 (which I only installed today) it produces a slightly smaller gcode file (65kb vs 69kb) but the gcode viewer works perfectly. It shows live progress slightly ahead of actual print - as has been mentioned before probably because of buffering at the printer. The "Printed" value as the print finishes however, is even worse - 87.5%
I have just had a look at the Prusa gcode and there are about 250 lines of comments at the end which is no doubt skewing things. My next test is to remove those comments and try again. No time now but I will do it asap.
I ran four tests - Prusa Cura Prusa Cura - just to be sure and the same results were seen each time. I will report back when I have tested the cleaned up Prusa gcode.