Update from 0.93.1 to the latest version - any risks?

I am running the server on Linux Mint 19 for my printers and it never failed me. I see the new version is released. Is the update as simple as installing the package over the old one? Will it remember my printer settings, etc.? Or will I have to set up everything again? Is there any way to backup and reload the settings across these versions? Thanks.


  • Please wait for 1.0.3 coming very soon - 1.0.2 has a bug you might not want also not printing related.

    Yes you update with autoupdater or just install the newer package. Configs are normally upgraded to new format adding new parameter but keeping the old one. As precaution make a copy of your printer xml config - also I never had this some users say that something changed. All other files are untouched but it might recompute timings for all gcode files.
  • Thanks. I am not sure how to start the auto update, mine shows there is no newer version from the web interface.
  • Should show 1.0.2 currently if you have internet connection. But you also can just download the deb package and run sudo dpkg -i packagename to install it. Thats the same the autoupdater does.
  • Is it using any special port? The computer should be connected to the internet, but through a firewall.
  • We use port 80 and 443 so just like any web browser.
  • What is the file name and location on Linux? I cannot find it. Also, checking for version says I am using actual version. The PC is online, I am now writing from it.
  • Does the server pc have internet connection? No idea why else it would not show an update otherwise.

    Anyway, just download the latest version on our homepage and install the deb packe with
    sudo dpkg -i failename.deb

    and you get your update as well.
  • I will do that, thanks.
  • I updated today. Everything seems to work fine and I even found the printer files to backup (in the installation instructions).
  • I actually found out that I have a problem after update. I keep getting a lot of these in the log:

    Send:12:01:35.768: M117 Layer 2/8
    Recv:12:01:35.849: Error:Wrong checksum
    Recv:12:01:35.852: Resend:23272
    Recv:12:01:35.852: Ignore due to resend: ok
    Send:12:01:35.937: Resend: N23272 M105
    Recv:12:01:35.943: ok 23272
    Send:12:01:35.943: Resend: N23273 G1 X-27.073 Y-12.011 E0.03781
    Recv:12:01:35.947: T:205.07 /205 B:60.00 /60 B@:0 @:48
    Recv:12:01:35.951: ok 23273

    What could be the cause? In the older version I never got these and the only thing I did to the setup was just the upgrade with dpkg as suggested above. I have not touched any hardware, nothing.
  • Das M115 show a CAP:autoreportTemp:1 ?
    Are always the same commands resend?
    Does printer reset during connect?

    I see you are using repetier firmware and due to line numbers these errors get detected on the fly without big delays. You might have gotten them previously as well. What is new that we now write:
    Ignore due to resend: ok
    but that is just for debugging and was previously just ignored. Important is that you do not have too much resends. But these are result of communication problems and outside servers responsibility. Different usb cable or baud rate can make them appear more often. Only thing where server might be responsible is when you have set input buffer too large. That would lead to errors due to loosing data before being read. In serial settings there is a wizard that tests different settings and error rate. But for quite a while the input size 127 should work well for repetier-firmware.
  • This came from FLSUN QQ-S Pro, which everyone tells it is Repetier based, but I do not thing so, even you confirmed that (and it does not work when I select Repetier firmware). Here are the logs (not from the same project) Foot middle is the old version, respirator hook the new version http://mysharegadget.com/315053912 - maybe you can find something interesting there

    I will try the wizard - maybe I was getting these errors as you say, silently. It does not affect quality on easy prints, but may have some connection with an object I printed recently - too much curves and G-Code and therefore printer stops and blobs. I will also try the optimizations you suggest on this forum and get a better cable.
  • Just to add - I tried testing the config with 127 bytes buffer and got over 1.7 % loss. 255 made it worse, 63 had zero resends. Maybe the printer has a smaller buffer than expected?
  • It very much looks like repetier firmware. Same ok format and also our eeprom handling.
    There was a time when arduino created 63 byte input buffers and when that causes no error compared to 127 I'd think this one is compiled with that. You can try M360 and if it is supported yous should see the buffer size in the answer. But in the end use what causes least errors. You can also try 80 byte so you use 63 byte in reality plus a reserve for emergency commands if supported. Just set 80 and try the active combination and see if errors are still 0.
  • Thank you for the great support, M360 said this: Config:InputBuffer:95 - so I had it wrong all the time without noticing. I set the buffer to 95 and zero errors.
  • Strange value but ok if it is set that way it explains the errors with 127 bytes.
Sign In or Register to comment.