New User - Unable to connect to Prusa MK3

Hello.  I am a new user looking to move from Octoprint to Repetier-Server.   So far I am not able to connect to my Prusa MK3s.  Details are;

- Prusa MK3s connected via usb to Intel based NUC running Ubuntu 20.04.2 LTS
- Repetier-Server Free 1.1.2

Octoprint connects flawlessly with the following settings;
- Serial Port: /dev/ttyACM0
- Baud: 115200

My first attempt at R-S connection settings;
- Firmware: Marlin
- Connection Method:  Serial Connection
- Device/Port:  /dev/serial/by-id/...
- Baud:  115200
- RTS:  Low to High
- DTR:  Low to High
- Buffering:   127

No connection can be made.  I have also modified device/port info to match the physical usb address as well as the same ttyACM0 that works with octoprint.  I have tried autodetect for the baud.  I have tried all variants of RTS/DTR.  I have used all variants of the buffering options.  It still errors out.  The System Error reported; "error:  Reading serial connection failed:  End of file.  Closing connection"  This repeats every 2 seconds.  The printer itself stays in a continuous reboot loop while the connection is attempted.

I have read through the FAQs and troubleshooting articles.  I did not find anything that pointed to a solution.  

Thanks in advance for any and all help figuring this out.

-Rob

Comments

  • @Rob - I am not official staff at all but I also recently moved my whole print farm to RS and love it.  Same scenario as you with several printers and I had to discover some fixes.  Just ahead of the curve I'll tell you - it's worth it.  RS is so much more stable and light-weight it's insane.  A single RPi 2 (yes 2, not 3B or 4) is running 3 printers with 0 issues for 6 days and huge GCode files.

    Anyway moving on -- 

    I had and randomly have the issue(s) you describe primarily on printers running firmware that is older than Marline 2.0.x aka Marline 1.x like many printers do.

    In my case there were a few things I did to drastically improve overall USB performance.  It would be helpful if you could specify what NUC you have and how it connects - built in USB ports? How many are there? etc.

    Anyway this article (it's for Raspberry but even if you use another NUC it applies): https://www.repetier-server.com/knowledgebase/undervoltage-and-throtteling-of-pi/

    Take special note of the Solutions section where you void the "5v" line on USB adapters.  If you ever noticed when you switch the printer off but it's connected to your NUC and the printer screen or some sensors stay on -- that is because it's leeching 5V.  This can cause noise and dirty signals depending on the power source and is also just annoying - I suggest at first taping over the 5V line, this made my USB in general so much more stable on all my 3D Printers.

    Next -- when setting up the printer under the USB Select the correct USB port listed (not the default one it picks, make sure to use a direct link to the tty/SO USB port) and also set the baud to 115200 for the Prusa MK3.  

    Make sure to pick the correct firmware type in the "Add Printer" options too and then test.  If it throws an error change the firmware to something else, change it back to the correct and hit "retest", most of the time this will cause it to fix and jump to the next stage of testing just fine.  Happens regularly to me and then works fine.

    There are also a few versions of the Prusa stock firmware that have some buffer issues which cause problems, there is a forum post about it: https://forum.prusaprinters.org/forum/original-prusa-i3-mk3s-mk3-general-discussion-announcements-and-releases/octoprint-issues-and-tips/


  • The prusa mk3 has one special problem -the port is visible even if the prusa is disabled. Then server tries to connect and fails, becaus eonly th eserial converter is powered by usb but not the avr2560 controller chip. In connection settings is a checkbox that th eport is also visible when not running which you should check for prusa. We just wrote it for this reason. That makes it not fail every 2 seconds if main power is not enabled.

    Otherwise with main power enabled your settings should work. Just make sure octoprint is not running same time or both might try to connect same time and break communication to each other.
  • Very much appreciate the response and thoughts.   I will start off with a positive update that I am now able to connect to my MK3!  The bad news is that I have absolutely no idea what changed to make it work.  Basically I left it overnight while I waited for feedback from this forum.  When got back on the next morning to check on some of the suggestions, I noticed that Octoprint reported that it had lost connection with the printer with an error related to something else taking the port.  I decided to give RS another crack at connecting and sure enough it connected right away, although it had an error about the FW type being set wrong (which is set correctly to Marlin).   I had a suspicion that the root of my problem was related to the port resource being previously assigned to octoprint, but the magic overnight behavior is strange for a couple of reason;
    1)  I had done everything short of removing Octoprint completely to make sure it wasn't holding the port hostage.  I stopped the service, powered down the printer, pulled the USB cable, reboot the server....everything I could think of.  
    2)  When I left the server overnight, Octoprint was connected happily and I had stopped attempted connections from the RS wizard (although I left the wizard page still up).  There should not have been any action that would have forcibly closed the port of Octoprint, and made it available for RS.  

    My next experiment was going to be install RS on my windows laptop and double check that I could connect that way.  But since it figured itself out, I never tried it.  Sorry for anybody stumbling on this thread looking for help with a similar issue.   I didn't come to a definitive conclusion.  For the sake of completeness, I will answer the questions from the posts above;

    @luis84
    - I am not sure the NUC model number, but the configuration is Intel Core i7-5557U @ 3.10GHz x4, 6GB memory.  Should not be possible to run into any undervolt or CPU throttling issues.  It has 4 on board USB ports for which the Prusa is connected directly.  I also have an old cheap USB hub as I did run out of ports (keyboard/mouse/webcam/etc).  I will be adding a Prusa Mini to the mix here shortly.

    - I originally tried all combinations of ports.  The default selection (/dev/serial/by-id/usb-Prusa...) is what I connected with.  I don't have tty/SO USB port.  I think the equivalent to what I see is /dev/serial/by-path/...  And yes as I mentioned I had been using 115200 from the start and is how it is connected now.

    - As I said above, I did get an error that I had the wrong FW type even though it is set correctly as Marlin.  I switched back and forth as you suggested, but I could get this error to go away, so I just accepted it with this error.  Later in my configuration, I used "autodetect values from firmware" and it seemed to work fine.  The FW version on my printer is up to date, so I don't thing those old FW bugs apply to my case.

    @Repetier
    - Thanks for the comment on the port visibility when powered down.  This option is not visible during the wizard.  But it is worth noting that my printer was powered on the entire time I was trying to connect, so this had no bearing on my issues.

    - I agree.  Like I said above, I am pretty sure this comes down to the OS and Octoprint not releasing the port.  See my comments on what I had tried to force the port free.  I could not find a way to list port active status from the OS to confirm if it was available for RS to connect to.

    Again, thanks to both of your the time responding.
    -Rob


  • @kingbuzzo Yeah that sounds correct, I have also had to accept the error then go back to printer settings and use the "retest" and it works.  It kinda sounds like somehow the port was still being locked up by another process or Octoprint.  I am a software dev (not with RS) and I think that explanation is lame but at the same time software misbehaves and who knows what was happening.  In the end physically only having RS server connected is ideal. 

    You should not run into under voltage with a full NUC but if you use a USB HUB I highly suggest an active hub with it's own power supply or you may start to get lost packets / resends and comm errors which can cause failed prints, blobs, zits, etc.

    Anyway welcome to the RS world.  I am a huge fan now.  I recently got successfully running and it's a beauty, the core to RS is insanely light and stable, hats off to the devs.
Sign In or Register to comment.