We had a customer contact us about Cura 3.2.21 pausing regularly for small periods of time and then resuming printing again. I have attached the File Log of the print the customer was attempting in hopes it will shed some light as to why this is happening. This issue is happening on a new computer with a fresh install of Cura 3.2.21, the computer is running Windows 10 for OS. I believe the customer was using our Rocktopus file.
|Resolved||Yahuba||T3157 Cura 3.2.21 consistent pausing - Checksum Errors|
|Resolved||karrad||T3785 Generate 22.214.171.124 FW|
|Resolved||Yahuba||T3786 Test pausing via SD|
|Resolved||Yahuba||T3812 Test Marlin 126.96.36.199|
|Resolved||Yahuba||T3838 Smoke Test 3.2.29|
|Resolved||alexei||T3844 Cura Backend quit|
|Resolved||karrad||T3710 Print freezes while smoke testing 3.2.28|
|Resolved||Yahuba||T3703 Smoke test 3.2.28|
I am not able to connect to the machine with Cura 21.08? Reading the error log, it looks like I'm getting random characters back from the printer.
Install Default FW is greyed out. I tried adding a new print head, got to the flash the firmware step, and got the error: "I am sorry, but Cura does not ship with a default firmware for your machine configuration."
Next, I tried flashing with the Taz 5 firmware on lulzbot.com; 188.8.131.52. Worked, could print.
Results with Cura 21.08, firmware 184.108.40.206: Needs calibration (overextruding).... but otherwise I'm not getting the USB errors.
Results with Cura 3.2.21, firmware 220.127.116.11: Needs calibration, and is still generating checksum mismatches / pauses.
@RyanFodder Thanks for running through that, and sorry for the connection issues! I had forgetting we changed the baud rate from 115200 to 250000 when going from Cura 21.08 to the 2.6 branch, and will likely be the cause of not being able to connect with the 3.2 firmware.
We will check into our USB plugin. Are you having any pausing issues if printing from SD card?
The customer got back in touch with us about trying to run print as admin and was still experiencing the same issues with pausing. They then tried printing the same GCode that they sliced using Cura that was failing through Pronterface and didn't encounter any of the pausing difficulty.
Customer also included this which I though was interesting and worth noting. "Another thing that I noted was that when printing the cylinder the printer doesn't move in a nice x and y sinusoidal pattern like it should for a circle. It was a little bit jumpy, and the resulting "cylinder" wasn't quite a cylinder. It was flatter on two opposing faces."
The only baud rates where you will not get checksum errors are 2400 and 250000, due to the need of having a baudrate which is a multiple of the MCU clock rate on the printer board. Any other baudrate will guarantee some number of GCODE lines will be corrupted, leading to checksum errors and retries. This is why we transitioned to 250000 a while back. However, since Cura can recover from checksum errors a lot of the times, a few occasional checksum errors are not a concern unless it stops or pauses the print.
Still having this issue, specifically on planetary gear prints. "Simple" prints without a lot of small details don't have this issue / maybe I don't notice as often.
I wanted to show what windows gives me for options:
This is frustrating - since the part I'm making relies on the quality of the print - its hard to turn gears if there are blobs of plastic in the way.
It would be very nice if I could make detailed parts again!
@RyanFodder We used to manually install RAMBo drivers, but have not needed to use them since we switched to Cura. (it installs it on setup) You can find the driver here if you would like to manually install it: http://download.lulzbot.com/TAZ/2.0/software/2013Q4/drivers/windows/
Have you tried another USB cable yet? If there is an issue there, it could be adding interference and the communication issues. If we can nail it down to that, we will be happy to send you out replacement.
@RyanFodder Ahh that is good, it means it is going to be an issue with that file and nothing hardware related. (RAMBos aren't too bad to switch out, but not something to do unless required.) The manifold errors are essentially gaps in the mesh, or vertices that are not connected properly. These errors can confuse the slicing engine about what travels need to be made and when. This will appear as if it is stuttering and having communication issues, where in fact it is following the gcode creation.
There is a good write-up on how to repair models using meshmixer here: https://www.lifewire.com/repairing-3d-files-with-meshmixer-2290
There is also a plugin in Cura LE that is called "Make printable" which is intended to repair a model for printing. This is not always perfect, and can cause repairs that are not intended. It is highly recommended to repair the file in the CAD program that it was generated in.
Printing the cube now; so far no errors. I was able to repair the gear file in NetFabb (STL generated in solidworks, and that also appears to have fixed the issue.
I haven't played with meshmixer, I might try that.
No errors so far, sorry to make you go through all this work for something silly.
@RyanFodder No need for apologies, I apologize it took me so long to check that file. It was some bad timing on us eliminating some checksum errors, and forgot to check the basics. As you are reporting the model fix seems to sort the issue, I am going to close this one down. Please let us know if this or any other issue pops up again.
@Yahuba Please test your windows 10 and 7 setups with the above STL file (PlanetaryV3_2(repaired).stl) posted by ryanfodder. I was unable to duplicate the issue on my set up last night.
@RyanFodder We are going to give it another attempt to replicate on our testing systems, if we are unable to I would suggest a RAMBo replacement. If this has not been replaced since the KITTAZ was first assembled, it may be time.
I ran this print using CuraLE 3.2.21 per the user's description (Windows 10). I dont have a Taz 5 in our lab but attempted the print on a Taz 6 with standard extruder. I did notice some brief pauses about half hour into the print which seemed to always occur in the same spot of the print. The pauses were very brief (2-3 seconds at most) and seemed to happen in groups of 2 or 3 pauses and typically in the transition between printing the cog wheels and the external wheel that holds the whole piece together. I captured it on a video attached here.
@RyanFodder Does this resemble the pauses you are seeing?
@Yahuba If you don't have any tickets on your plate, can you slice and attempt on this print for the windows machine. If it persists, please try with combing turned off.
@RyanFodder Looking at the generated gcode, I see some unnecessary travel moves. (Nothing too out of the ordinary) Can you try the above file, and if the issue persists turn off combing as well? This is almost the identical file you submitted, and known working.
Yes, I saw a bunch of checksum mismatch errors in the log. Example:
2018-09-25 12:52:18,486 - INFO - [(2620)-MainThread] USBPrinting.USBPrinterOutputDevice._log : USBPrinterOutputDevice: Resending from: 83407
2018-09-25 12:52:48,080 - INFO - [(2620)-MainThread] USBPrinting.USBPrinterOutputDevice._log : Error:Line Number is not Last Line Number+1, Last Line: 85205
2018-09-25 12:52:48,085 - INFO - [(2620)-MainThread] USBPrinting.USBPrinterOutputDevice._log : USBPrinterOutputDevice: Resending from: 85206
2018-09-25 12:52:48,116 - INFO - [(2620)-MainThread] USBPrinting.USBPrinterOutputDevice._log : Error:Line Number is not Last Line Number+1, Last Line: 85205
@karrad Printing "bearing5": the print worked great for 36 minutes with no issues, then had two pauses back to back with corresponding checksum errors. Since that first error, there has now been several in the space of a couple minutes.
The errors started to occur roughly 31-32% of the way through the print.
I got very intermittent checksum errors when printing this file - it got worse the farther into the print it got. There were a couple hard pauses ~40%-45% in, and it got worse from there.
I scaled to 40% because the print was quite large - only a 1.5 ish hour print and still generated the same errors as the gear file.
Attempted to print the PlanetaryV3_2(repaired) .stl file in Ubuntu Xenial system connected to a Taz6 with a Dual v.2 extruder that was connected to it and also got checksum mismatch errors.
Started some prints on our Mac and Debian systems as well and will update the ticket once they are done.
I have three additional prints of the same file running on the following system/printer configurations:
Ubuntu (16.04) - Mini/Standard Mini extruder
Debian (Stretch) - Taz6/MOARStruder
OS X (El Capitan) - Taz6/DualExtruder v3
All three are already showing checksum mismatch errors in the log, however, I have only been able to visibly see any pausing in the print with the print running on the Mac OS X system.
*UPDATED COMMENT: the print running on the Ubuntu system ultimately ended in a freeze without completing the print. I have uploaded that log as well. Will upload the Mac OS X log once the print completes.
The main computer I've been using is ASUS G751JT (gaming laptop) that has the following specs:
- i7-4710HQ processor (2.5 GHz)
- 16 GB Ram
- Running windows 10
I also tested on an older laptop, an HP Envy 17 laptop:
- i7-2670QM processor (2.2 GHz)
- 8 GB Ram
- Running windows 7
Certainly willing to try - just a heads up that I'll be slower to respond starting the 1st when I go back to work.
Attempted a print from the Ubuntu 16.04 system connected to a Mini (Mini Standard Extruder) using the hexfile posted above. The print completed, however I noticed there were checksum mismatch errors in the log and noticed some bubbles on the print. I did use the .stl file from T3157 (the repaired version). I will attempt printing a different file with this same Firmware to see if I get any errors or pause bubbles in the print.
I have been experiencing a similar issue on the Mini 2 on my desk. I am currently running Cura LE 3.2.28 and the Firmware is 18.104.22.168. I'm also printing from SD. It will stall / pause at different heights. It was sliced on a work computer as well.
Attempted to print a different file (3DBenchy.stl) using the same configuration as my last post. Did not see any pausing and don't see any pause bubbles on the piece itself. I also scanned through the log and couldn't spot any checksum mismatch errors.
Hi everyone. I have a theory that some of these problems may caused by the printer's CPU simply not having enough time to service the serial port fast enough. We have made at least three changes which could have made things worse in that regard:
- Increased LCD comm time to combat LCD freezes (introduced 22.214.171.124)
- Added LIN_ADVANCE to all printers (introduced 126.96.36.199)
- Added backlash compensation to all printers (introduced 188.8.131.52)
These feature were not added at once, but it is possible that having all three in place is enough to cause us problems. Here is some experimental FW which reverses all these changes. Please let me know if it behaves better with regards to serial checksum issues specifically (regardless of print quality or LCD freezes). I have tried to include FW for all the printers/toolheads mentioned in this thread, but if I forgot one, let me know.
I am about 16% of the way through a print using the 184.108.40.206 TAZ5 firmware. The errors are back and as often / severe as before. I've already observed several dramatic pauses, and have seen ~20 checksum errors.
The 115200 baud rate firmware so far has seen the best results.
Edit for comparison:
getting 5-6 errors per minute with 220.127.116.11 firmware. (dozens of observable bubbles)
was getting 1 error / 5 minutes with 115200 baud rate firmware (3 total bubbles on final print)
So far testing these three:
and all three are showing checksum mismatch errors in the log already and they are all between the 20% and 30% mark. I cant see any visible pausing as of yet.
Some updates on the other two prints I ran on Friday:
The mini/single extruder ended up freezing towards the end of the print. Here is the log:
Dual v3 log:
Going to attempt printing bearing5.stl with the other two FW .hex files I have not tried yet.
Attempted a print of bearing5.stl on the mini2 with Aerostruder v2 firmware 18.104.22.168 and the print froze completely as it was starting (still at 1%).
Also printed same file on Mini (LCD) with standard extruder using FW 22.214.171.124 and completed succesfull print with no pauses. Couldn't not find any checksum mismatch errors when scanning through the log.
@RyanFodder We did some re-writes of the serial communication protocols, and have been having good success locally. If you would like to give it a try while we smoke test the various operating systems, you can find Cura LE 3.2.29 here: http://devel.lulzbot.com/software/cura-lulzbot/windows/
@RyanFodder: The checksum errors are entirely outside of anything we can control, the only thing we can do is improve the recovery after a checksum error occurs. If you are not noticing any significant pauses and the prints are finishing okay, then the error recovery is doing its job.
@RyanFodder: If you want to do any additional checks, one interesting thing to try would be the 115200 baud FW with the new Cura. Whereas before you were getting fewer errors with 115200 baud FW than with the 250000 baud FW, my guess is that now they will perform about the same. The differences in error rate you were seeing before was likely due to Cura not being able to recover properly, which I think have largely been resolved with this Cura update.
I checked the print this morning... There were no significant bubbles. The gear/bearing was able to spin freely after the print with no clean up at all.
I would say this is a major fix!
I was reporting the errors mainly for your team's benefit. If the errors do not result in bubbles / pauses / print errors, then I'm ok with that!
I'm willing to run the 115200 FW print, but I don't have a good method of comparing them if the prints turn out well in both cases.
I'm willing to run the 115200 FW print, but I don't have a good method of comparing them if the prints turn out well in both cases.
@RyanFodder: If you're satisfied with the new release and print quality, then no need to run additional tests :) Thank you for your help nailing this down!
I had some time to test
TAZ 6 AeroStandard
Fresh USB cable provided by @karrad with no hub
I am still getting checksum errors, however I am not seeing pauses evident in print defects. I wish I had taken a moment to post my terminal logs... But looking at a 9 hr print, it reported maybe 5 or 6 checksum errors. I will grab that terminal log and post it here this evening. The first print I had attempted was about 5 hours and reported only 3 checksum errors if I remember correctly.
This may not be entirely solved, but is certainly a HUGE improvement, and the least amount of errors I have seen while USB printing since upgrading to CuraLE 2.6.xx, I had two prints (5hrs&9hrs) complete without noticeable defects!
@logan: Eliminating checksum errors was not the goal -- in fact, I think a certain number of checksum errors are inevitable -- the goal was to properly correct for those errors in a manner in which the user was not affected by them. It sounds like that goal was achieved with this last round of fixes.