Attempting to upload a gcode file to the printers SD card. I have also seen a similar situation during a print, but the upload is easier to reproduce. Simply upload a very large (in this case 20MByte) gcode file using the "Upload to Sd" button.
Upload to complete with no error.
Upload stopped with repeated messages "Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves."
Looking at serial.log it seems that the command to get a fresh response from the print (M105) is not being sent. I have also (once) seen a hang during printing and believe that this was a similar problem, but the upload to SD card is easier to reproduce.
Yes
1.3.10
OctoPi 0.15.1
I3 clone running Marlin Bugfix 2.0.x on MKS Sbase 1.3
Chrome v 71.0.3578.98 on Windows 10
https://drive.google.com/open?id=1M0R8BszFdQutkDcE2RMU8Lcdb3Rxcdha
https://drive.google.com/open?id=1-xSNTeoLwulpfu8wWkooH2FWJ4TifOZm
N/A
N/A
I have read the FAQ.
Please also see the following thread: https://discourse.octoprint.org/t/communication-timeout-when-uploading-to-sd-m105-not-being-sent/6136
I was just about to comment on your proposed change related to that, then noticed that I wasn't in a PR, deleted the comment again and then realized that you haven't yet created a PR for the above commit.
So it became a comment on the commit after all. Still happy to get a PR for that though :)
From the looks of it the problem here is indeed that the communication gets stuck (which I take it from the forum topic you've traced back to the block in select). What I need to fix however is that OctoPrint thinks it can tickle the communication back into functioning with an M105 when streaming to SD, which would lead to the M105 to be written to the file instead of being executed. In principle a valid approach to bring the communication back, but also a side effect which I'm unsure right now whether it's even acceptable. Then again it's minimally invasive since it just queries state and (usually) doesn't modify it in any way.
Sorry I didn't have the time to actually write up the PR, but will hopefully do so shortly!
No worries, happens. I just thought I'd overlooked something for a second there. PR is merged. And I think I'll leave the attempt to tickle communication back into working via M105 even while streaming to SD, it's probably better to have an extra M105 in the file on the SD if push comes to shove than duplicated lines or a stuck upload.
From your comments I take it that this should be it already? Can you still reproduce this issue with the patch in place?
With the patch in place everything seems to work fine, no errors reported and no timeouts. I've also been running Octoprint on Windows to gather some upload times there. The original bug does not seem to be present on Windows (not a big surprise), both the unpatched and patched version seems to run fine with the patched versions giving slightly faster results.
Yes I don't think it is really worth trying to avoid the m105 problem.
Great, marking this as solved then. Thanks for not only a thorough report but even doing the analysis and providing the solution :)
1.3.11 was released yesterday.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.