The print progress figures on my Octopi setup are lagging behind the actual print. It is on the latest 1.4.0 rc5 version running on a Pi 3B+ (OctoPi 0.15.1) but I don't think it's a bug as other people would have noticed it. Nothing is broken - anything I throw at it (an Ender 3) prints fine but as a print progresses, the percentage complete, current layer, and sync'd gcode viewer gradually lag behind what is actually being printed. For example, on a print with 400 layers, as the last layer is printed the reported progress and current layer is around 96% and 385 respectively. If I do a quick calculation of the displayed Printed/Total file size figures it works out at 96% but what it has actually printed is over 99%. When the print finishes the numbers jump to 100% and 400 and everything is fine.
I have a few plugins but running in Safe Mode still shows the same issue.
I haven't done any logging yet as it isn't a show stopper and as I said above I don't think it's a bug. I am just curious if anyone else has experienced anything similar or has any suggestions to fix it.
I have a Windows 10 machine and use Chrome Version 79.0.3945.130 - but I am pretty sure it isn't a browser issue. My Ender 3 has been modified with an MKS Gen L V1.0 Controller and runs stock Marlin V1.1.9
Any thoughts welcome.
Quick edit. Based on previous comments by foosel I have checked the gcode files and there isn't any huge additional stuff at the end. I use Cura to slice and there is just a few lines of config data at the end of each file.
Hmmm... I don't think so - but I have done a few mods to the printer since that release. Too many variables! I will see if I can load 1.3.12 onto a spare SD card and do some experiments.
Finally had some time to look at this & remembered I cloned my 1.3.12 SD before upgrading to the 1.4 dev version. And with 1.3.12 I can confirm this doesn't happen. If anything, the gcode viewer displays a second or two earlier than the actual print head position but it stays this way throughout the print.
Watching the gcode viewer on 1.4rc5 it seems to "pause" for a few seconds occasionally and never catch up. As if something is sucking away its processor cycles.
The only other thing I can think of which is different between the two setups is the SD card which I am going to clone to a new card and see if that has any effect.
I am also going to have a look at log files (never had to before now) and see if that gives any clues.
Hi,
Just to say I am having the same problem after updating to Octoprint 1.4.0 running my CR10s. Everything else seems to be running fine apart from the tardy GCode Viewer.
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?
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 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.
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.
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.
