What's the deal with Serial autodetection?

Get Help
1

I don't really need help since it all works, this is more about understanding what happens.

What is the problem?

I configured Marlin (2.0.9.1) for 250000 baud instead of the prior 115200 baud.
Then set the connection settings top-left to AUTO on port and AUTO on baud rate and turned the printer's power on. the log goes like:


2021-11-24 18:17:01,423 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Detecting serial connection"
2021-11-24 18:17:01,479 - octoprint.util.comm - INFO - Serial detection: Performing autodetection with 7 port/baudrate candidates: /dev/ttyACM0@115200, /dev/ttyACM0@250000, /dev/ttyACM0@230400, /dev/ttyACM0@57600, /dev/ttyACM0@38400, /dev/ttyACM0@19200, /dev/ttyACM0@9600
2021-11-24 18:17:01,480 - octoprint.util.comm - INFO - Serial detection: Trying port /dev/ttyACM0, baudrate 115200
2021-11-24 18:17:01,481 - octoprint.util.comm - INFO - Connecting to port /dev/ttyACM0, baudrate 115200
2021-11-24 18:17:01,495 - octoprint.util.comm - INFO - Serial detection: Handshake attempt #1 with timeout 2.0s
2021-11-24 18:17:01,502 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-11-24 18:17:03,505 - octoprint.util.comm - INFO - Serial detection: Handshake attempt #2 with timeout 2.0s
2021-11-24 18:17:03,515 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-11-24 18:17:05,472 - octoprint.util.comm - INFO - Changing monitoring state from "Detecting serial connection" to "Operational"
2021-11-24 18:17:05,510 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-11-24 18:17:05,626 - octoprint.plugins.stats - INFO - Printer Stats - on_event
2021-11-24 18:17:05,955 - octoprint.util.comm - INFO - Printer reports firmware name "Marlin 2.0.9.1 (Nov 24 2021 15:56:51)"

And this is, what the ui tells me: 115200.
Did a test print, no problem whatsoever.
Disconnected, set baudrate to 250000, connect.
OctoPrint is fine with it:


2021-11-24 18:22:26,704 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Opening serial connection"
2021-11-24 18:22:26,713 - octoprint.util.comm - INFO - Connecting to port /dev/ttyACM0, baudrate 250000
2021-11-24 18:22:26,759 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial connection" to "Connecting"
2021-11-24 18:22:26,775 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-11-24 18:22:26,794 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-11-24 18:22:26,805 - octoprint.util.comm - INFO - Changing monitoring state from "Connecting" to "Operational"
2021-11-24 18:22:26,931 - octoprint.plugins.stats - INFO - Printer Stats - on_event
2021-11-24 18:22:26,953 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-11-24 18:22:27,304 - octoprint.util.comm - INFO - Printer reports firmware name "Marlin 2.0.9.1 (Nov 24 2021 15:56:51)"
2021-11-24 18:22:27,372 - octoprint.util.comm - INFO - Firmware states that it supports temperature autoreporting
2021-11-24 18:22:27,452 - octoprint.util.comm - INFO - Firmware states that it supports emergency GCODEs to be sent without waiting for an acknowledgement first

Another test print, all is smooth.

Still, I'm confused.

  • Does the baud rate not matter? I'd have expected an error.

  • Auto-detection did not detect Marlin's configured baud rate even though 250000 is one of the values it states to check. Apparently it received a handshake on the first attempt and settled for that.

octoprint-systeminfo-20211124183221.zip (676.7 KB)

This is 1.7.2 on 0.18.0, raspi 3B+

2

So, usually the auto connect works by building pairs of ports and most common baudrates, then iterating through them and picking the first that works.

I have no idea why in your case it works with both 115200 and 250000, usually I've only ever seen garbage come back with the wrong baudrate. Chip might not care about the baudrate then, 32bit board?

3

True, a 32bit, early BTT SK mini E3 v1.2 in an Ender 3. Marlin is built for STM32F103RC_btt_USB

It does feel like the board and the raspi do some low level magic and then sort of ignore what is configured somewhere up.
Is there some (debug) way to force auto detection to actually step through the entire list of pairs and check all 7 of them? That wouldn't change much in my case as it already accepts the max, it would only check on the "ignore" part.

4

Nope, currently there's no such thing. I frankly never saw the need, given that the earlier it connects, the better, and who am I to complain then :sweat_smile:

5

Ok, guess I'll have to accept that the system fails to throw errors on me then.
Still curious what is happening there.
Thanks for your time, foosel!

1 Like
6

Once you have found a baudrate that works for your controller, there is no need for OctoPrint to keep trying different baudrates each time when you connect, so you might as well just use a specific value rather than "AUTO". The baudrate that the controller expects usually does not change, so there really is no need to keep trying different baudrates.

7

Yes, you focus on the "all works" part of the original post's first sentence. But my focus is more on the "understanding" part.
I was hoping for someone to step out of the shadows and explain why I don't get drowned in funny letters when OctoPrint is configured to use a wrong baud rate.
Did some more reading, it lead me to terms like 'USB-CDC', 'CDC-ACM' (control device class abstract control management) and searching for these landed me in tutorials for usb device driver programming. I had not planned to get that close to the metal, curiosity kills the cat. And I doubt I really understood what I read but it gave me the impression that in fact the two usb endpoints have their own means of determining how fast data flow with flow control while the baud rate tells the driver which size of buffer to use when talking to the other side (OS).
What I read discussed things for an STM32 chip which happens to be the sort of chip in my printer's mb.

Encouraged by that I manually set the baud rate to 19200, OctoPrint again was fine with it,


2021-11-25 16:30:22,790 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Opening serial connection"
2021-11-25 16:30:22,799 - octoprint.util.comm - INFO - Connecting to port /dev/ttyACM0, baudrate 19200
2021-11-25 16:30:22,854 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial connection" to "Connecting"
2021-11-25 16:30:22,876 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-11-25 16:30:22,885 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-11-25 16:30:22,911 - octoprint.util.comm - INFO - Changing monitoring state from "Connecting" to "Operational"

Serial.log is still plaintext, the printer prints fast, printtimeGenius still thinks the part will take 12min to finish.

My takeaway from this is that, at least with my BTT sk mini E3 motherboard, the baudrate config is purely decorative. I think I'll leave it at 19200, brings back old memories of modems on analog landline and loading games and pictures from bulletin boards in the 1980's.

8

In that case I'd set it to 9600 for the full retro feeling ^^

1 Like
9

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.