Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Communication timeout after N38/N39 with Octoprint 1.4.0 and DisplayLayerProgress version 1.18.1 #128

Closed
Kelly12612 opened this issue Mar 26, 2020 · 18 comments
Closed

Communication timeout after N38/N39 with Octoprint 1.4.0 and DisplayLayerProgress version 1.18.1 #128

Kelly12612 opened this issue Mar 26, 2020 · 18 comments
Labels
status: markedForAutoClose Issue will be closed automatically status: waitingForTestFeedback type: bug Something isn't working

Comments

@Kelly12612
Copy link

My printer is a Prusa MK3s firmware 3.8.1-2869 with MMU2s firmware 1.0.6-372.
After upgrading to octoprint 1.4.0, my first two prints aborted with a communication error.
I did some testing and found that the same thing happened if I just uploaded a gcode file to the SD card.
I did a lot more testing and found that the problem only occurs if the DisplayLayerPlugin is enabled, if I disable that, everything works, even with all my other plugins enabled.

It happens with gcode files from PrusaSlicer versions 2.1.1 and 2.2.0 (ga).

I've attached a terminal log from a failed send, and the octoprint.log file from a failed send.

The problem always seems to occur after an N38 or N39 command, one example is:
Recv: ok
Send: N39 G92 E0.0*99
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.

Let me know if there is any other information you'd like, it's pretty easy to reproduce.
terminal_log_march_26_0940.txt
octoprint.log
@OllisGit
Copy link
Owner

OllisGit commented Apr 3, 2020

Hi @Kelly12612,

which Python-Version do you use?
If possible, please attach the original sliced g-code from the slicer and also the upload g-code downloaded from OctoPrint-Menu.

@OllisGit OllisGit added the status: waitingForFeedback Wating for Customers feedback label Apr 3, 2020
@Kelly12612
Copy link
Author

This was an upgrade, so it appears to still be running the older python:
pi@octopi:~ $ python -V
Python 2.7.16

@Kelly12612
Copy link
Author

dlp_128_original.txt
dlp_128_downloaded_from_octoprint.txt

@OllisGit OllisGit added status: inNextRelease Will be implemented/fixed in next release type: bug Something isn't working and removed status: analysing status: waitingForFeedback Wating for Customers feedback labels Apr 6, 2020
OllisGit added a commit that referenced this issue Apr 8, 2020
@OllisGit
Change to async gcode processing
6341392 
Bugs
#134, #124, #128, #131, #127, #126
Enhance
#132 State-Section
101, #117 option to deactivate adding M117 layer-indicators
@OllisGit
Copy link
Owner

OllisGit commented Apr 8, 2020

Hi @Kelly12612
in the newest release 1.19.0 I changed the behaviour (switching to async) of processing the gcode during print. I think this was your issue, because the gcode was not send fast enough to the printer.

Because it is just an assumption, please test and give me a feedback.

Thx, in advance
Olli

@OllisGit OllisGit added status: waitingForTestFeedback and removed status: inNextRelease Will be implemented/fixed in next release labels Apr 8, 2020
@Kelly12612
Copy link
Author

The problem is still happening for me with the new release. I've attached a smaller gcode file that reproduces the problem. If I try to copy this to the SD card through Octoprint with this plugin enabled, it gets partway through then I get a communications error/reset (failed 3 times in a row).
If I disable the plugin and restart, the file is transferred successfully.

SuperLubeTube_and_cap_x3_PLA_0.15mm_PLA_MK3SMMU2S_2h4m.zip

@Kelly12612
Copy link
Author

Kelly12612 commented Apr 18, 2020 via email

@OllisGit
Copy link
Owner

To be honest, currently I have no idea how to analyse this....but I want to mention one point: local vs sd card-upload

Local
upload goes to the pi. OctoPrint can listen on gcode and could adjust it (like DLP)
SD
goes over the serial connection to the SD card in the printer. During the print OctoPrint can't listen/manipulate gcode, because it is directly send to the print (DLP don't work). Datatransfer is faster.
More information, see https://community.octoprint.org/t/ouch-sd-card-vs-octoprint-what-a-difference-help/8618

@OllisGit
Copy link
Owner

One idea: I looked into your Serial log again and some printers had issues with "special-characters" for the M117 display command.
Try to send the following commands to your printer via terminal to reproduce the error.

M117 INDICATOR-Layer1

and

G92 E0.0

Maybe the printer can't handle - and the next command could not be send.....just an idea!

@Kelly12612
Copy link
Author

Kelly12612 commented Apr 19, 2020 via email

@OllisGit
Copy link
Owner

Hi @Kelly12612,

last idea: Try latest development version https://github.com/OllisGit/OctoPrint-DisplayLayerProgress/releases/download/1.20.1dev/master.zip

This version use queing-hook and is not interfering the communication between OP and Printer.
The values in the display are now a little bit behind.

@Minglarn
Copy link

How to update to 1.20.1dev from octoprint?

@Kelly12612
Copy link
Author

Kelly12612 commented Apr 25, 2020 via email

@OllisGit
Copy link
Owner

@Minglarn use the plugin-manager http://docs.octoprint.org/en/master/bundledplugins/pluginmanager.html and enter the above master.zip-url into "from URL" and press install.

@OllisGit
Copy link
Owner

Hi @Kelly12612 ,

hmm..short Summary: Two problems

  1. Upload to printers SD-Card is not possible, if plugin enabled
  2. Sending gcode during print from OP-RasPI-FlashCard throws communication-error.

Lets focus on issue 1)

  • You upload the gcode via Browser-UI und choose SD-Card (Drag&Drop right-side), right?
  • What error do you receive if upload failed? Please attach the OctoPrint-Log.

@Kelly12612
Copy link
Author

dlp_issue_128.zip

@Kelly12612
Copy link
Author

Kelly12612 commented Apr 26, 2020 via email

@OllisGit
Copy link
Owner

Short status update:

  • I looked into your logs and I am wondering why the printer stops receiving data only after 3 seconds
2020-04-25 19:19:11,695	Changing monitoring state from "Operational" to "Sending file to SD"
...
2020-04-25 19:22:12,492 No response from printer after 6 consecutive communication timeouts, considering it dead.
2020-04-25 19:22:12,563 Changing monitoring state from "Sending file to SD" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"
  • Maybe a combination of the "exclude-plugin" raise this issue, because the "exclude" also use a file-preprocessor during the upload

Do me a favour and test uploading files with disabled "exclude-plugin".

Thx, in advance
Olli

@stale
Copy link

stale bot commented Aug 5, 2020

This issue has been automatically marked for closing, because it has not had activity in 30 days. It will be closed if no further activity occurs in 10 days.

@stale stale bot added the status: markedForAutoClose Issue will be closed automatically label Aug 5, 2020
@stale stale bot closed this as completed Aug 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
status: markedForAutoClose Issue will be closed automatically status: waitingForTestFeedback type: bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@OllisGit @Kelly12612 @Minglarn