[BUG] (Printer Hangs midprint, heaters on, Marlin 2.0)

[dawjr]

Hey, Guys - forgive me for posting errors. I've read all I can about this problem, seems I'm not alone. But wanted to make sure this issue is kept alive because it seems to be most debilitating where trust in a machine is non-existent.

Just upgraded two FT-5 printers to Marlin 2.0 bugfix, 32bit SKR 1.3, TMC2208 on axis' running standalone, TFT35. One machine is 12v other is 24v. Always run from SD in controller. Machines ran flawlessly before upgrade.

Simply put - machines work well and as expected. 12v machine will hang (heaters on), typically into a deep print (hours) controller freezes, reset will have the controller asking to "resume print?" which it will do, but it may or may not hang again. I'm not positive, but 24v machine may have hung during initial testing, but 24v machine seems to be most trustworthy. 12v machine PSU upgraded from 360w to 480w, but issue persists.

I've read as much as I can find here and other places - (a windows framework maple upgrade is beyond my comfort zone) As another poster allowed, we/I simply need reliability the reliability that was intact before 2.0. Willing to help all I can and make any adjustments that I'm able. Of course this is a dangerous condition, hanging with extruder and bed on.

If this is not the correct place to post this, let me know or feel free to move.

All the best, Don

Bug Description

Printer Hangs midprint, heaters on

My Configurations

Required: Please include a ZIP file containing your Configuration.h and Configuration_adv.h files.

Steps to Reproduce

Problem can't be reliably reproduced. Same G code will produce success or failure. Environmental conditions seem irrelevant.

1. [First Step]
2. [Second Step]
3. [and so on...]

Expected behavior: [What you expect to happen]

Completed print, no issues.

Actual behavior: [What actually happens]

Printer may or may not stop during print, display appears fine, but touching reveals that it too has hung. A reset is necessary to regain control. Touching "Print" will have the controller asking to "Resume Print?" Which does work, but print shows evidence of this stop/start, not a best solution. Printer may continue on after restart, or may hang several more times.

Additional Information

• Provide pictures or links to videos that clearly demonstrate the issue.
• See How Can I Contribute for additional guidelines.

[Miraculix200]

You could test if the same thing happens when you print over USB. Maybe it's SD card read errors

[boelle]

My Configurations

Required: Please include a ZIP file containing your Configuration.h and Configuration_adv.h files.

[dawjr]

Configuration_adv.zip

Thank you - here are the configuration files.

New info - I was just able to catch the TFT with the message, "Busy Processing, Please wait" - the display was frozen and the only recourse was/is to reset. This is the first time that I've seen/caught this message, perhaps it may or may not display this based on where it is in the processing at the time. But this seems to be a huge clue. And, this happened just after a successful printing of the same Gcode. So, there is an intermittent wild card that is coming into play.

Of course this is a trying problem. Any and all help would be appreciated.

Miraculix - others that have reported this same problem report that it happens either way. I've printed for years only with SD cards. Don't want to go through the learning curved (at this point) only to find there's no difference or benefit.

All the best, Don

[jtrmal]

This has happened to me as well on SKR Mini E3 1.4 while printing from Octoprint. Octoprint complained the printer stopped responding (too many timeouts). It's not reproduceable easily, though (happened twice in two weeks worth of time)
This is last few lines from octoprint terminal, if it would be useful...

Send: N22582 G1 X86.438 Y98.381 E706.13404*100
Recv: ok
Send: N22583 G1 X86.779 Y98.005 E706.16633*111
Recv: ok
Send: N22584 G1 X87.135 Y97.642 E706.19867*109
Recv: ok
Send: N22585 G1 X87.517 Y97.287 E706.23185*105
Recv: ok
Send: N22586 G1 X87.919 Y96.942 E706.26554*102
Recv: ok
Send: N22587 G1 X88.319 Y96.627 E706.29793*104
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.

Edit: I'm on the bugfix-2.0.x branch

[jtrmal]

Forgot my config
Archive.zip

[swilkens]

Does this also happen when you start a PID autotune over the serial connection? I'm having a fairy similar issue.

It happens very repeatably for me.

#19187

[jtrmal]

I did try pid autotune over octopi terminal and worked fine. But the lock up has been very stochastic... One model failed two times (on different layer) and printed fine the third time.

…

On Sat, Aug 29, 2020 at 19:26 swilkens ***@***.***> wrote: Does this also happen when you start a PID autotune over the serial connection? I'm having a fairy similar issue #19187 <#19187> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19148 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUKYX2YI4TQJBXKV3Y2H4TSDE26BANCNFSM4QK3KLGA> .

[nanotuxi]

UPDATE: Have to apologize. After some days of testing it was a broken sd card which was the root cause for my problem here. Sorry.
Same here. Printing a very large gcode file (about 60MB) printed half and then suddenly stopped and failed.
Display message: Printer ready, so seems to have had a reset/reboot?
Examinated the gcode file on the sdcard. Nothing corrupted, all o.k. afaik
Motherboard: MKS Gen L v1.0
Marlin version: 2.6.0
PID autotune from usb serial works flawlessly.
Small prints were all o.k.
All motor or stepper driver temperature was o.k. during the whole print (no overheating). Motherboard beiing cooled with two fans.

[jtrmal]

I tried a newer version of firmware -- now I'm at 1e124e6.
Just happened again:

Send: N114425 G0 F9000 X133.75 Y118.583*69
[...]
Recv: ok
Send: N114426 G1 F1500 X86.25 Y118.583 E1423.24514*9
Communication timeout while printing, trying to trigger a response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.

In the dmesg from octopi I saw there errors:

[191687.168998] usb 1-1.3: USB disconnect, device number 15
[191687.169239] cdc_acm 1-1.3:1.0: failed to set dtr/rts
[191692.329346] usb 1-1.3: new full-speed USB device number 16 using dwc_otg
[191692.462525] usb 1-1.3: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00
[191692.462544] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[191692.462556] usb 1-1.3: Product: Maple
[191692.462568] usb 1-1.3: Manufacturer: LeafLabs
[191692.463877] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
[197246.720842] usb 1-1.3: USB disconnect, device number 16
[197246.721070] cdc_acm 1-1.3:1.0: failed to set dtr/rts
[267719.207918] usb 1-1.3: new full-speed USB device number 17 using dwc_otg
[267719.341137] usb 1-1.3: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00
[267719.341155] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[267719.341168] usb 1-1.3: Product: Maple
[267719.341180] usb 1-1.3: Manufacturer: LeafLabs
[267719.342880] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
[272337.408299] usb 1-1.3: USB disconnect, device number 17

Any suggestion how to track this down? Is there any option to enable some more verbose tracing of what's going on inside the Marlin that would help?

[dawjr]

Hey, Guys - I've been working on this issue and have found that there may have been (or still is) an issue with the firmware on the TFT35 BigTreeTech display. I've had a suspicion that my problems were linked to it somehow. I'm able to reproduce the "random stoppage" by simply pulling the SD card during the print - head stops moving (of course) and the hotend and bed stay energized. So, this seems to me to be a "read" error when it happens during a print. If you visit their GitHub and read through some of their bugfixes, some of the item relate to solving random stoppages. Flashing the display board with their latest firmware is similar to the SKR board, in this case placing the bin file and the text/icon file in the root of an SD card, plugging into the display board and power cycling the unit. Anyway - it will remain to be seen if this solves this problem, but initial test prints completed fine. In reading their version histories, it seems that the same bugfixes were applied to all of their displays, TFT28-TFT70, Biqu and Bigtreetech. You may want to check these possible solutions for yourself. Fingers crossed on this end.

All the best, Don

[github-actions]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[github-actions]

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.