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
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?
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?
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.
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
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.
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.
