Jump to content
Ultimaker Community of 3D Printing Experts

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


anon4321

Recommended Posts

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

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

 

  • Link to post
    Share on other sites
    Posted · Did 15.01 RC9 update Arduino Drivers? Checksum errors...

    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.

     

  • Link to post
    Share on other sites
    Posted · Did 15.01 RC9 update Arduino Drivers? Checksum errors...

    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?

     

  • Link to post
    Share on other sites
    Posted · Did 15.01 RC9 update Arduino Drivers? Checksum errors...

    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!

     

  • Link to post
    Share on other sites
    Posted · Did 15.01 RC9 update Arduino Drivers? Checksum errors...

    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.

     

  • Link to post
    Share on other sites
    Posted · Did 15.01 RC9 update Arduino Drivers? Checksum errors...

    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/

     

  • Link to post
    Share on other sites
    Posted · Did 15.01 RC9 update Arduino Drivers? Checksum errors...

    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.

     

  • Link to post
    Share on other sites
    Posted · Did 15.01 RC9 update Arduino Drivers? Checksum errors...

    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.

     

  • Link to post
    Share on other sites
    Posted · Did 15.01 RC9 update Arduino Drivers? Checksum errors...
    Link to post
    Share on other sites
    Posted · Did 15.01 RC9 update Arduino Drivers? Checksum errors...

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

     

  • Link to post
    Share on other sites
    Posted · Did 15.01 RC9 update Arduino Drivers? Checksum errors...

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

     

  • Link to post
    Share on other sites
    Posted · Did 15.01 RC9 update Arduino Drivers? Checksum errors...

    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.

     

  • Link to post
    Share on other sites
    Posted · Did 15.01 RC9 update Arduino Drivers? Checksum errors...

    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.

     

  • Link to post
    Share on other sites
    Posted · Did 15.01 RC9 update Arduino Drivers? Checksum errors...

    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!

     

  • Link to post
    Share on other sites

    Archived

    This topic is now archived and is closed to further replies.

    ×
    ×
    • Create New...