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

[anon4321 16]

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

 

[anon4321 16]

Most likely something on my end. I uninstalled the driver and reinstalled using the instructions here:

Step 4: http://arduino.cc/en/guide/windows

Same version uninstalled was the same version reinstalled.

However, my issue went away....

 

[anon4321 16]

Nope spoke too soon....

 

[Daid 306]

Nope, drivers haven't changed in like... forever.

 

[anon4321 16]

Thanks Daid, yeah I noticed that no matter where the drivers come from, they are all 1.0.0.

Wonder if you could tell me -

Have there been any changes in Cura that would impact the checksum calculation?

Is there a way in Cura to log the serial comm so I can see if the checksum is correct?

Thanks in advance.

 

[anon4321 16]

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?

 

[bosque 0]

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!

 

[anon4321 16]

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.

 

[anon4321 16]

I'm leaning towards an issue in BigDataStorage. I was able to capture the raw data sent back from the slicer and it looks fine with only a space where it is broken in the output previously posted.

http://umforum.ultimaker.com/index.php?/gallery/sizes/12031-curaissue/large/

 

[Daid 306]

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.

 

[anon4321 16]

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.

 

[Daid 306]

https://github.com/daid/Cura/commit/a7639122e7732ff5c001cc66ea1ef3c991e6c3a0

This patch might just fix it.

 

[anon4321 16]

Cool, I'll give that a try tonight and let you know...

 

[anon4321 16]

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

 

[Daid 306]

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.

 

[anon4321 16]

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.

 

[bosque 0]

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!