Page MenuHomeAleph Objects Inc

Cura 3.2.21 consistent pausing - Checksum Errors
Closed, ResolvedPublic

Description

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.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Here is the ticket ID for this issue, I apologize about not making sure this was part of the original post.

Ticket ID: 170245

@Darian No problem, thanks for getting it on there for us. Any chance you can reach out and see what their IT team found? You can also let them know the github fix as described in the ticket was for an older branch (1.1.0) and is included within 1.1.8

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; 1.1.5.70. Worked, could print.

Results with Cura 21.08, firmware 1.1.5.70: Needs calibration (overextruding).... but otherwise I'm not getting the USB errors.
Results with Cura 3.2.21, firmware 1.1.5.70: 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?

I don't have the ability to print from SD card, unfortunately.

alexei triaged this task as Normal priority.Jul 27 2018, 8:32 AM
alexei changed the edit policy from "All Users" to "Cura LulzBot Edition (Project)".
alexei removed a subscriber: glatti.
In T3157#56132, @karrad wrote:

@Darian No problem, thanks for getting it on there for us. Any chance you can reach out and see what their IT team found? You can also let them know the github fix as described in the ticket was for an older branch (1.1.0) and is included within 1.1.8

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."

@RyanFodder Can you check under device manager, and port settings to see what your rate is set to? We recently had a report of Windows changing the baud rate to 9600, which could explain the pausing you are running into. This should be set to 250000

Yup - 9600. There isn't a 250,000 setting, highest I see is 128000.

No issues at 128000. Thanks!!!

@karrad (Should have tagged in above post)

@RyanFodder Great to hear, thank you for trying that out for us!

@Darian Please contact the poster of the original ticket, and see if he can update his com port settings within the device manager.

@karrad @RyanFodder is the original customers IT Professional who is handling the situation. So the original customer is taken care of!

karrad closed this task as Resolved.Aug 3 2018, 2:26 PM
karrad claimed this task.

@Darian @karrad I apparently spoke too soon. If I try to print the following file, it still has the checksum issue even at 128,000 baud rate.

I wonder if its because of the complexity?

marcio added a comment.Aug 3 2018, 4:00 PM

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.

Its definitely pausing the print. Is there a way to get 250,000 as an option on the port? Driver change maybe?

marcio added a comment.Aug 6 2018, 8:46 AM

@RyanFodder: That I do not know. Perhaps somebody else does?

karrad reopened this task as Open.Aug 6 2018, 8:46 AM

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!

karrad added a comment.Sep 4 2018, 7:42 AM

@RyanFodder We have been unable to duplicate this in all of our windows testing environments, have you tried swapping your USB, trying another USB port on the computer, or a different computer all together?

@karrad I was able to get another laptop using Windows 7 up and running to try this. I still get the same port settings as shown above (except on COM6).

Is there a recommended USB driver / Rambo driver I should be using instead?

@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.

Both cables have had the same issue. I don't have others to try.

@RyanFodder Looking back through this ticket, can we have you try a different STL file? The one you posted earlier has 9,900+ manifold errors and can be causing the pausing issue you are seeing.

If you can, please give this one a try and let us know:

This comment was removed by RyanFodder.

It does seem to be only this file.

@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.

karrad closed this task as Resolved.Sep 24 2018, 1:23 PM

I actually spoke too soon - its definitely catching on the fixed file :(

Here is the repaired file that I get errors on. It doesn't seem to have errors until about 20 minutes in.

karrad reopened this task as Open.Sep 24 2018, 2:51 PM

@RyanFodder That model is looking correct. I am running the same one on a Mini 2 right now with linux, and will give it a try tonight on my TAZ 5 with Windows. What filament profile and quality setting are you using?

karrad reassigned this task from karrad to Yahuba.Sep 25 2018, 7:23 AM

@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.

Yahuba added a comment.EditedSep 25 2018, 10:07 AM

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?

This is the same as as I see. The net result is a little blob on the print (which needs to be trimmed for the print to work.)

What speed does windows have your port set to @Yahuba ?

@RyanFodder Windows 10 defaults my machine to 9600 Baud rate and like you pointed out earlier in the thread, the max baud rate available is 128000.

@karrad
I was also able to replicate the pauses with this print using CuraLE version 3.2.27 (which flashed firmware to 1.1.9.16). Same as in the video I posted in my last test run.

@karrad Here is the gcode file generated by CuraLE 3.2.27

@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.

@Yahuba I had spaced requesting the log, are you seeing checksum errors as well?

Yahuba added a comment.EditedSep 25 2018, 1:15 PM

@karrad
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 [53]: USBPrinterOutputDevice: Resending from: 83407
2018-09-25 12:52:48,080 - INFO - [(2620)-MainThread] USBPrinting.USBPrinterOutputDevice._log [53]: 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 [53]: USBPrinterOutputDevice: Resending from: 85206
2018-09-25 12:52:48,116 - INFO - [(2620)-MainThread] USBPrinting.USBPrinterOutputDevice._log [53]: 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.

@RyanFodder Okay, it looks like we will need to do some more digging into the checksum errors. Is this just happening on this type of model, or have you had a chance to try something else that is a few hour print?

karrad renamed this task from Cura 3.2.21 consistent pausing to Cura 3.2.21 consistent pausing - Checksum Errors.Sep 26 2018, 10:26 AM

I will investigate if I can find another definitive example.

One more update, I was able to replicate this with my windows 7 system as well. Once again more checksum mismatch errors.

@Yahuba Please try with linux and mac as well for this model file. fwiw I have not seen it on stretch

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.

This photo shows some if the resulting blobs on the surface (right side of the part.)

I think this shows what's happening in more detail.

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.

Yahuba added a comment.EditedSep 27 2018, 9:32 AM

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.

@RyanFodder Can you provide full system specs for the computer in issue? Looking at 1.1.5.70 was not giving errors, we are also going to work up a FW version for you at a 115200 baud rate to experiment with if you are willing.

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.

karrad added a comment.EditedSep 27 2018, 1:22 PM

@Yahuba Please try to duplicate the pause on Ubuntu via USB on Mini Standard Extruder using this FW set to 115200:

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 1.1.9.17. 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 1.1.9.12)
  • Added LIN_ADVANCE to all printers (introduced 1.1.9.18)
  • Added backlash compensation to all printers (introduced 1.1.8.64)

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.






RyanFodder added a comment.EditedSep 28 2018, 1:02 PM

I am about 16% of the way through a print using the 1.1.9.19 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 1.1.9.19 firmware. (dozens of observable bubbles)
was getting 1 error / 5 minutes with 115200 baud rate firmware (3 total bubbles on final print)

@RyanFodder Can you check you cpu and ram usage while the pausing is going on?

So far testing these three:
Dual v3
Moarstruder
Mini Single

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.

Here is the log for the test print on the MOAR Struder:

@karrad CPU usage 1-4% and memory for Cura is 630,600 K. (Using the older laptop at the moment.)

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.

Yahuba added a comment.Oct 1 2018, 2:15 PM

Attempted a print of bearing5.stl on the mini2 with Aerostruder v2 firmware 1.1.9.19 and the print froze completely as it was starting (still at 1%).

Also printed same file on Mini (LCD) with standard extruder using FW 1.1.9.19 and completed succesfull print with no pauses. Couldn't not find any checksum mismatch errors when scanning through the log.

karrad added a comment.Oct 2 2018, 2:49 PM

@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/

Its printing similarly to the 115200 baud rate Firmware: a checksum error every few minutes, but no noticeable pauses (that I've noticed.)

marcio added a comment.Oct 3 2018, 7:57 AM

@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.

marcio added a comment.Oct 3 2018, 8:05 AM

@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.

Also, thank you to all of you for the dedicated support!

karrad added a comment.Oct 3 2018, 8:45 AM

@RyanFodder Thank you for all the help testing and patience while we worked it out. We are going to wait to close this one out until we finish smoke testing multiple operating systems, but all signs point to @marcio 's fix to be the trick!

marcio added a comment.Oct 3 2018, 8:47 AM

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!

logan added a comment.Oct 8 2018, 7:54 AM

I had some time to test
CuraLE 3.2.30
Marlin 1.1.9.17
Ubuntu 18.04
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.

logan added a comment.Oct 8 2018, 10:28 AM

@marcio I agree, I wasn't sure if those checksum errors were a normal facet of Cura USB printing as I hadn't looked for the issue prior to having problems.

karrad closed this task as Resolved.Oct 11 2018, 3:20 PM

No pausing on smoke test, closing this one out as resolved. Thanks again @RyanFodder!

karrad closed subtask T3703: Smoke test 3.2.28 as Resolved.