Jump to content
Ultimaker Community of 3D Printing Experts
Sign in to follow this  
anon4321

Did 15.01 RC9 update Arduino Drivers? Checksum errors...

Recommended Posts

Today I updated to RC9 after using RC8 successfully for many prints.

Now I get checksum errors and the print stops.

I went back to RC8 and still have the issue with checksum error. However, it is printing successfully from the SD card.

I can't say for sure that something isn't broken on my side.

The last set of prints were running off of a pcduino running octoprint. It's possible the pcduino overdrove the usb input and the board might be oversensitive to noise but IDK....

 

Share this post


Link to post
Share on other sites

Daid, it looks likes there could be an issue with Cura. Not sure, could be a hardware problem on my machine. For the files below, I'll PM you a link to a zip.

With Cura 15.1-RC8, if I slice Tresse_Arm.stl using the Tresse_Arm.ini, the results are shown in Cura.log.

To get Cura.log, I added this a line to machineCom.py:

self._log("Unexpected error: %s" % (getExceptionString()))

checksum = reduce(lambda x,y:x^y, map(ord, "N%d%s" % (self._gcodePos, line)))

self._callback.mcMessage("Sending N%d%s*%d" % (self._gcodePos, line, checksum))

self._sendCommand("N%d%s*%d" % (self._gcodePos, line, checksum))

Cura sends a two lines that looks like this (from Cura.log):

< Sending N54G0 F13500 X66.20*61

< Sending N551 Y91.000*16

 

But the gocde should have been (as shown in Tresse_Arm.gcode):

G0 F13500 X66.201 Y91.000

 

This seems to confuse the firmware.

 

If I clear the platform and use Tresse_Arm.gcode directly, the problem doesn't occur.

 

Thoughts?

 

Share this post


Link to post
Share on other sites

I started getting checksum errors in 15.01 R9 after upgrading from R8 as well. I'm using Win8.1 and printing via USB to an Ultimaker Orginal. I'm able to save the gcode generated by R9 and print without issues using Printrun.

Before reading anon's post, I thought it was communications related and tried the following to isolate the issue.

-Uninstall and reinstall arduino driver

-Reflashed the Ultimaker with the firmware in R9 and the version on Ginge's marlin builder.

-New USB cable

-Uninstall all version of Cura (checked registry and Program Files) and reinstalled R9

Thanks!

 

Share this post


Link to post
Share on other sites

I've tracked this back in the code and it is HIGHER up in the processing. EVERYONE is potentially affected by this.

I added some logging lines in serialConnection.py. This routine loads the output of the slicer into memory -

 


#Load the data into memory for printing, returns True on success
def loadGCodeData(self, dataStream):
if self.isPrinting() is None:
return False
self._gcodeData = []
tempLog = open("c:\\users\\Internet\Desktop\\CuraIssue0.log", "a")
tempLog.write('Stream:\n')
for line in dataStream:
tempLog.write(line)
tempLog.write('-----')
#Strip out comments, we do not need to send comments
if ';' in line:
line = line[:line.index(';')]
#Strip out whitespace at the beginning/end this saves data to send.
line = line.strip()

if len(line) < 1:
continue
self._gcodeData.append(line)
tempLog.close();
return True

The output of the test is:

 


-----G1 X70.801 Y108.700 E47.97552

-----G1 X70.801 Y96.300 E48.96752

-----G1 X65.801 Y96.300 E49.36752

-----G1 X65.801 Y90.600 E49.82352

-----G0 F13500 X66.201----- Y91.000

-----G1 F600 X75.601 Y91.000 E50.57552

-----G1 X75.601 Y100.300 E51.31952

-----G1 X138.800 Y100.300 E56.37544

-----G1 X138.800 Y104.700 E56.72744

-----G1 X75.601 Y104.700 E61.78336

Noticed the ----- in the middle of the line. This indicates that the code is interpreting this single line as two lines when it is sent down stream. This will result in bad gcode being sent to the printer causing the original problem.

Cura is using a class called BigDataStorage which is doing some manipulation to get around memory limits.

I haven't been able to walk back into that code to know if the problem occurs in that code or if it originates in the slicer or in the code that receives the output of the slicer.

Hopefully Daid will see this. This could cause some random quality issues as the split gcode can't be recovered.

 

Share this post


Link to post
Share on other sites

I'm leaning towards an issue in BigDataStorage.

 

That sounds like a pretty good possibility.

 

EVERYONE is potentially affected by this.

 

My guess is on only USB printing is effected by this. And only if the GCode size is over a certain amount of size.

And, could be that plugins play a part in this as well.

 

Share this post


Link to post
Share on other sites

Oh yes, that was a qualified everyone. Everyone printing over USB and over a certain size. Although, the size is relatively small. This issue occurs on the first 60-70 or so lines of gcode.

I'm not sure plugins factor into this as I'm not using any and it is occurring in the load of the output of the slicer. The slicer output looks OK. However, just after the slicer output is loaded into the BigDataStorage object, dumping the BigDataStorage object shows that the issue occurred. I'm not sure plugins intercept things between those two points.

I'll look into it more tonight (EDT) and let you know what I find.

 

Share this post


Link to post
Share on other sites

Daid it looks like that patch fixes the issue.

However, I'm still seeing a lot of checksum errors:

< Error:No Line Number with checksum, Last Line: 54

< Error:No Line Number with checksum, Last Line: 83

< Error:No Line Number with checksum, Last Line: 114

< Error:No Line Number with checksum, Last Line: 157

 

However, at least now the print isn't halting like it did before....

 

Share this post


Link to post
Share on other sites

Daid it looks like that patch fixes the issue.

However, I'm still seeing a lot of checksum errors:

< Error:No Line Number with checksum, Last Line: 54

< Error:No Line Number with checksum, Last Line: 83

< Error:No Line Number with checksum, Last Line: 114

< Error:No Line Number with checksum, Last Line: 157

 

However, at least now the print isn't halting like it did before....

 

That's because Cura is intentionally forcing buffers to be full on the firmware side. Which sometimes causes checksum errors. These are corrected and re-send.

 

Share this post


Link to post
Share on other sites

Thanks, I suspected that was the case. I looked at the arduino schematic and there is no flow control between the ATmega16U2 handling the USB connection and ATmega2560. So I guess buffer overruns are simply something that occurs and the firmware handles by requesting a resend.

However, your fix helped. With one print, the whole system of Cura and the printer just seem to stop.

 

Share this post


Link to post
Share on other sites

Finished a sucessful print within Cura 15.01 R11 via USB. The gcode for the print was 87mb. Thank you both for finding the issue and fixing it.

 

I started getting checksum errors in 15.01 R9 after upgrading from R8 as well. I'm using Win8.1 and printing via USB to an Ultimaker Orginal. I'm able to save the gcode generated by R9 and print without issues using Printrun.

Before reading anon's post, I thought it was communications related and tried the following to isolate the issue.

-Uninstall and reinstall arduino driver

-Reflashed the Ultimaker with the firmware in R9 and the version on Ginge's marlin builder.

-New USB cable

-Uninstall all version of Cura (checked registry and Program Files) and reinstalled R9

Thanks!

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

Terms of Use Privacy Policy