After upgrading to 1.4.1, OctoPrint won't connect to Prusa MK3s -

After updating to OctoPrint 1.4.1, I am no longer able to connect to my Prusa MK3S. I am running Octoprint on OctoPi 0.17.1 with Python 2.7.16 on a RasPi 4 2GB. The Pi boots and I am able to connect using via the web interface, but when I click on Connect (Serial Port Auto, Baud Rate Auto), I get the error: could not write to serial port. I am connecting via USB plugged into one of the USB2 ports on the Pi.

If I manually choose the serial port as Dev/tty/ACM0, the Prusa reboots, then OctoPrint gives the error: No more candidates to test, and no working port/baudrate combination detected.

If I manually choose the serial port as Dev/tty/AMA0, the Prusa does not reboot, and I get the OctoPrint error: Could not write to port.

There have been zero physical changes between a working connection under 1.4.0 an hour ago, and the update to 1.4.1

Log attached octoprint-3.log (115.6 KB)

1 Like

So, after a bit of trial/error, I discovered that if I restrict the baud rate to 115200, I am able to connect. Not sure why it won't when set to AUTO as it used to do fine under 1.4.0, and the log file indicates that it did try this connection, but was unsuccessful.

You need to use the PROPER USB port in Octoprint...
/dev/ttyUSB0 is the port when you are connecting via USB. /dev/ttyAMA0 and /dev/ttyACM0 are serial ports on the GPIO pins

Good grief! I wonder why it let me connect via that port for the last 9 months (I migrated from a Pi Zero connected to GPIO fr the first year and a half). And now that I think about it, that shouldn't be an issue anyway as I did a clean install from the OctoPi download
I do not see /dev/tty/USB0 as an option. And when I add it to the Additional Serial Ports, it doesn't show up. Is this an OctoPi configuration thing?

If I remember correctly, Prusa does some pre-config on their image, to get the serial-over-GPIO thing to work. Don't know how to undo that, but you could try taking a backup and getting a new OctoPi image?

EDIT: Snap! Just seen you updated the post :slight_smile:

I just updated my last reply to say that what I used to use shouldn't even be a factor as it was a clean install when I got the Pi 4 using the OctoPi package download.

I just ssh'd into the Pi, and indeed the /dev directory is missing the ttyUSB0 file (or any file with USB in the title).
Is there a way to download that file (from I don't know where) so that I don't have to reinstall the complete Octopi package again, then restore from a OctoPrint backup?

it's not /dev/tty/USB0, it's /dev/ttyUSB0. and it won't show until the printer is powered on.

dave-octopi:~# ls /dev
autofs gpiochip0 loop6 ram0 random stdout tty21 tty36 tty50 tty8 vcs3 vcsu4
block gpiochip1 loop7 ram1 raw tty tty22 tty37 tty51 tty9 vcs4 vcsu5
bsg gpiomem loop-control ram10 rfkill tty0 tty23 tty38 tty52 ttyAMA0 vcs5 vcsu6
btrfs-control hwrng mapper ram11 sda tty1 tty24 tty39 tty53 ttyprintk vcs6 vga_arbiter
bus i2c-1 media0 ram12 sda1 tty10 tty25 tty4 tty54 ttyS0 vcsa vhci
cachefiles initctl media1 ram13 sda2 tty11 tty26 tty40 tty55 ttyUSB0 vcsa1 vhost-net
char input mem ram14 serial tty12 tty27 tty41 tty56 uhid vcsa2 video10
console kmsg mmcblk0 ram15 serial0 tty13 tty28 tty42 tty57 uinput vcsa3 video11
cpu_dma_latency kvm mmcblk0p1 ram2 serial1 tty14 tty29 tty43 tty58 urandom vcsa4 video12
cuse log mqueue ram3 sg0 tty15 tty3 tty44 tty59 v4l vcsa5 video13
disk loop0 net ram4 shm tty16 tty30 tty45 tty6 vchiq vcsa6 video14
dma_heap loop1 null ram5 snd tty17 tty31 tty46 tty60 vcio vcsm-cma video15
fb0 loop2 port ram6 spidev0.0 tty18 tty32 tty47 tty61 vc-mem vcsu video16
fd loop3 ppp ram7 spidev0.1 tty19 tty33 tty48 tty62 vcs vcsu1 watchdog
full loop4 ptmx ram8 stderr tty2 tty34 tty49 tty63 vcs1 vcsu2 watchdog0
fuse loop5 pts ram9 stdin tty20 tty35 tty5 tty7 vcs2 vcsu3 zero

Yes, the extra / in my post was a typo. My printer is on, connected via USB cable (though through the ttyACM0 serial port because that's all that I've got and it's working), and there is no ttyUSB0 located at /dev on the Raspberry SD card.

pi@Prusa-MK3S:/dev $ ls
argon-h264mem    cuse       input         mapper              port   ram2            rpivid-hevcmem  tty1   tty20  tty31  tty42  tty53  tty7       vc-mem  vcsa4     vga_arbiter
argon-hevcmem    disk       kmsg          media0              ppp    ram3            rpivid-intcmem  tty10  tty21  tty32  tty43  tty54  tty8       vcs     vcsa5     vhci
argon-intcmem    dri        log           mem                 ptmx   ram4            rpivid-vp9mem   tty11  tty22  tty33  tty44  tty55  tty9       vcs1    vcsa6     video0
argon-vp9mem     fd         loop0         memory_bandwidth    pts    ram5            serial          tty12  tty23  tty34  tty45  tty56  ttyACM0    vcs2    vcsm      video10
autofs           full       loop1         mmcblk0             ram0   ram6            serial1         tty13  tty24  tty35  tty46  tty57  ttyAMA0    vcs3    vcsm-cma  video11
block            fuse       loop2         mmcblk0p1           ram1   ram7            shm             tty14  tty25  tty36  tty47  tty58  ttyprintk  vcs4    vcsu      video12
btrfs-control    gpiochip0  loop3         mmcblk0p2           ram10  ram8            snd             tty15  tty26  tty37  tty48  tty59  uhid       vcs5    vcsu1     watchdog
bus              gpiochip1  loop4         mqueue              ram11  ram9            stderr          tty16  tty27  tty38  tty49  tty6   uinput     vcs6    vcsu2     watchdog0
cachefiles       gpiochip2  loop5         net                 ram12  random          stdin           tty17  tty28  tty39  tty5   tty60  urandom    vcsa    vcsu3     zero
char             gpiomem    loop6         network_latency     ram13  raw             stdout          tty18  tty29  tty4   tty50  tty61  v4l        vcsa1   vcsu4
console          hwrng      loop7         network_throughput  ram14  rfkill          tty             tty19  tty3   tty40  tty51  tty62  vchiq      vcsa2   vcsu5
cpu_dma_latency  initctl    loop-control  null                ram15  rpivid-h264mem  tty0            tty2   tty30  tty41  tty52  tty63  vcio       vcsa3   vcsu6
pi@Prusa-MK3S:/dev $

I know this won't help you Peel, but I have a MK3S, only had it about a month. Updated to 1.4.1, last night and no connecting issues. I am running 0.18 beta because I'm on a 8GB Pi4, but...

Mine is also connecting to dev/ttyACM0, and has been before and after the 1.4.1 upgrade. No print or connection issues at all.

So I'll be following this... cuz if my connection info is wrong too, I'd like to know how to get the 'right one' in there.


I'm confirming your issue.
Same problem here aswell on two different setup (separate Pi and separate printers on separate location) Prusa MK3S and my MK3s with MMU2s. Restricting the baudrate did solve the problem but why this comes up after 1.4.1 is a big question. I'm also lacking the ttyUSB0 and my serial port is set as Dev/tty/AMA0.
Very very strange.

It helps to read the change log or at the very least the release notes, those usually tell you what changed which might explain changes in behaviour you are seeing :wink:

Auto detection was rewritten from scratch in 1.4.1.

I've noticed that at least my MK3 sometimes "freezes" during startup, meaning trying to connect to it won't work within sensible timeouts, which are shorter for auto connecting than regular connecting (otherwise you'll have to wait for ages while it cycles through ports and baudrates). Disconnecting and reconnecting then will make it boot up fine. Seems to be a firmware or electronic quirk with the prusa machines that I've not yet gotten to the bottom to. In any case, if you know your baudrate and are running into timeouts, just set it.

Auto detect should really only be used if you don't know your connection parameters, though for most machines it should now work better in 1.4.1, but only if their firmware actually behaves predictably.

1 Like

Yeah but if re.written the beta team would have found this before going public with the release? The normal user don't know its baudrate or even know how to find it so the auto setting is worth its weight in gold.

For the record, the beta "team" is regular users just like you who decide to participate in testing on their own. Development is still pretty much a one woman show done by yours truly. I don't know all of the testers, I don't even know how many of them are there unless they have enabled anonymous usage tracking. I have to rely on enough people volunteering each and every RC cycle to have a diverse enough runtime environment to identify such issues beforehand. What they report or what I notice myself I can fix, what doesn't get reported I can't fix.

Nothing like this was identified other than what I already mentioned above (and that is an issue that will not only make auto detect fail but manual connect as well) so whatever problem you are running into here, it is as of yet unidentified and unanalysable, and some "normal" users have to do their part to help narrow down on it. So please, if this is reproducible for you, open a full bug report so this can be looked into.


I'm running 1.4.1 on am MK3S with MMU. Python 2.7.13, Octopi 0.16.0 RPI3B+ Connection set to AUTO:
connects to dev/ttyACM0 @ 115200 without issue.

apparent difference in Octopi (0.16.0 vs 0.17.1), RPI3B+ vs RPI4, and MK3SMMU vs MK3S

Do you have the latest Prusa firmware installed?
Perhapse Octopi beta 18 might help

[Cadmonkey4life]: can you comment on your Octopi builds?