Jump to content
Ultimaker Community of 3D Printing Experts

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


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

    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
    • Our picks

      • Startups, apply for the Forward AM Innovation Award!
        Are you a startup using 3D printing? Perhaps you should continue reading... 
         
        Together with BASF we are launching the Forward AM Innovation Award - the very first global contest for startups developing new applications with 3D printing!
         
        Why apply?
        The winning startup will receive €100,000 in goods and services*, along with coaching and marketing exposure from top-notch leaders in the industry.
         

         
        Who can apply?
        Your startup creates products using Additive Manufacturing, is less than 5 years old, and has less than 50 employees. We are looking for 3D printing applications with a strong focus on innovation, sustainability and scalability.
         
        Dental aligners, shoes, tools, automotive parts, music instruments, industrial tooling and molding, medical implants, sports equipment, toys, architecture, fashion, construction... all are welcome to join!
         
        Do you have an innovative, sustainable and scalable idea that leverages the unique possibilities of 3D printing? Then it is time to apply!
        More information can be found here.
         
        Applications close on March 28th, 2021
        * What does "in goods and services" mean?
        The winner will be able to pick any item from the overall product and service portfolio of the sponsors, e.g. printers, materials, consulting, software... Choose whatever you need to accelerate your startup.
         
          • Like
        • 0 replies
      • New here? Register your Ultimaker for free 3D printer onboarding course
        Hi,
         
        Often getting started is the most difficult part of any process. A good start sets you up for success and saves you time and energy that could be spent elsewhere. That is why we have a onboarding course ready for
        Ultimaker S5 Pro Bundle, Ultimaker S5, Ultimaker S3 Ultimaker 2+ Connect.   
        They're ready for you on the Ultimaker Academy platform. All you need to do to gain access is to register your product to gain free access. 
        Ready? Register your product here in just 60 seconds.
          • Like
        • 0 replies
    ×
    ×
    • Create New...