Checksum / Communication issues when upgrading from 0.94.3 to 1.0.0/1.0.1

edited December 2020 in Bug Reports
After upgrading to 1.0.0 I began to have degraded print quality. There were seemingly random movements away from the print area and then back to printing normally.  Looking at the Console page, there were MANY checksum and wrong line number errors.  Over the course of a three hour print the Connection Information popup showed 10's of thousands of connection errors.  Upgrading to 1.0.1 made no change.  After downgrading back to 0.94.3 I have had zero communication errors and beautiful prints again.  I made no setting changes between upgrading and downgrading.  I have two Geeetech printers with Atmega 2560 based boards running Marlin 2.0.7.2.  Running pro version of server on an intel 64 bit Ubuntu system.

Comments

  • On 1.0.1 my printer works as expected ,checksum errors disappeared after reducing buffers from 255 to 127.
    You can check for the best setting in Printer Settings-> Communication
    there´s a button "Test multiple configs" so there you can check and select the best

    My printer uses 255 by autodetect , but checking shows errors so i reduced to 127 and problems disappeared
  • edited January 2021
    After upgrading to 1.0.1 I also did the comm rest and interestingly I had better results with 255 instead of the default 127, but I am using the SKR 1.4 Turbo board and the Pro version running on 32-bit Raaspberyy pi 3b.
  • Ok , I use Rumba32 board , Repetier Firmware V2 and Repetier server Pro on Pi3B
  • If higher buffer leads to less errors that is a random result. Normally it would be the other way around. With my SKR 1.3 board I can not get any errors at all regardless of buffer. Seems like it just blocks new data when not ready to receive more and since it is a native usb that might even work and be the reason.
  • Thank you.  I used the new communication test button and found that I needed to reduce the buffer to 127.  It now works great.  It was set in the 300's and just seems odd to me that it had to be reduced so much after the upgrade.
  • Not really. I rechecked my changes and in old version after 5 com errors I silently reduced buffer size to 63 which then stoppen your errors. Now we hold the buffer size so you keep getting com errors from buffer being to big as soon as commands take time in firmware.
  • Ok, that makes sense.
Sign In or Register to comment.