Octopi Connection Issue SOLVED  

Re: Octopi Connection Issue SOLVED

I was on 3.4.1 for a few days with no issues using OctoPrint. Last night OctoPrint refused to connect. Was seeing an attempt to connect via the terminal, initial response and then timeout. Downgraded to 3.4.0 and all fine again - thanks. Ironically I had issues with the filament sensor at 3.4.1 with white PLA(have not investigated issues so could be dirty sensor but only recently rebuilt so would be surprised). Leaving filament sensor disabled.

Re: Octopi Connection Issue SOLVED

I just performed the Mk2 to Mk2.5 upgrade this weekend and also had problems connecting my Octopi to the new 3.4.1 firmware. My settings were as before the upgrade with a baud rate of 115200. I noticed the Terminal view showed that the Octopi made the initial connection, and received responses from the printer, but then timed out after a "MMU not responding - DISABLED" response.

Connecting to: /dev/ttyACM0
Changing monitoring state from "Offline" to "Opening serial port"
Connected to: Serial<id=0x701df3b0, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from "Opening serial port" to "Connecting"
Send: N0 M110 N0*125
Recv: echo: 3.4.1-1356
Recv: echo: Last Updated: Oct 4 2018 17:44:04 | Author: (none, default config)
Recv: Compiled: Oct 4 2018
Recv: echo: Free Memory: 2045 PlannerBufferBytes: 1392
Recv: echo:Hardcoded Default Settings Loaded
Recv: adc_init
Recv: PAT9125_RES_X=0
Recv: PAT9125_RES_Y=240
Recv: PAT9125_init:1
Recv: FSensor DISABLED
Recv:
Recv: echo:SD card ok
Recv: MMU not responding - DISABLED
There was a timeout while trying to connect to the printer
Changing monitoring state from "Connecting" to "Offline"
Connection closed, closing down monitor


Since it appeared that the Octopi was connecting, I took a shot and set the Baudrate to "AUTO" and tried again. This time it worked and Octopi is talking to my Mk2.5 with the latest 3.4.1 firmware. It still appears to connect at 115200 after the auto detect, but there is just enough different about the sequence of events that keeps it from the initial timeout.

Connecting to: /dev/ttyACM0
Changing monitoring state from "Offline" to "Opening serial port"
Connected to: Serial<id=0x684738b0, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Starting baud rate detection...
Changing monitoring state from "Opening serial port" to "Detecting baudrate"
Trying baudrate: 115200
Send: N0 M110 N0*125
Recv: echo: 3.4.1-1356
Recv: echo: Last Updated: Oct 4 2018 17:44:04 | Author: (none, default config)
Recv: Compiled: Oct 4 2018
Recv: echo: Free Memory: 2045 PlannerBufferBytes: 1392
Recv: echo:Hardcoded Default Settings Loaded
Recv: adc_init
Recv: PAT9125_RES_X=0
Recv: PAT9125_RES_Y=240
Recv: PAT9125_init:1
Recv: FSensor DISABLED
Recv:
Baudrate test retry #1
Send: N0 M110 N0*125
Recv: echo:SD card ok
Recv: ok
Changing monitoring state from "Detecting baudrate" to "Operational"
Send: N0 M110 N0*125
Recv: ok
Send: N1 M115*39
Recv: FIRMWARE_NAME:Prusa-Firmware 3.4.1 based on Marlin FIRMWARE_URL: https://github.com/prusa3d/Prusa-Firmware PROTOCOL_VERSION:1.0 MACHINE_TYPE:Prusa i3 MK2.5 EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
Recv: ok
Send: M20
Recv: Begin file list
Recv: CHECKP~1.GCO 146
Recv: V2CALI~1.GCO 785
Recv: End file list
Recv: ok
Send: M105
Recv: ok T:26.9 /0.0 B:27.7 /0.0 T0:26.9 /0.0 @:0 B@:0 P:27.2
Send: M105
Recv: ok T:26.9 /0.0 B:27.7 /0.0 T0:26.9 /0.0 @:0 B@:0 P:27.2
Send: M105
Recv: ok T:27.0 /0.0 B:27.7 /0.0 T0:27.0 /0.0 @:0 B@:0 P:27.2


So far everything seems to be working fine....

Re: Octopi Connection Issue SOLVED

Thank you for sharing! Helped me a lot!

Re: Octopi Connection Issue SOLVED

I just had this issue. It seemed to connect instantly once i enable the filament sensor?

Maybe this is coincidence but i may help someone who googles the issue.

Re: Octopi Connection Issue SOLVED

I have never had any connection issues until upgrading to octoprint 1.3.10 (stable). After upgrading I was unable to connect, receiving a baudrate error every attempt. I flashed to the most recent firmware and tried setting the baudrate manually to 115200 with no success. I saw the post about turning the filament sensor on and figured I would try it since nothing else was working... Success! I have no idea why disabling the filament sensor would prevent octoprint from connecting but perhaps the Prusa team should look into this. I have had little success with printing with the sensor on which basically means that I can't use octoprint...

RE: Octopi Connection Issue SOLVED (not really)

This is still an issue with the latest Prusa Firmware. I've been investigating this problem, and figured out the reason why octoprint fails on first connection.

When OctoPrint attempts to connect, you will see the following:

Send: N0 M110 N0*125

On successful connect, you will see this:

Recv: ok

With the current Prusa firmware (v3.7.0), on the very first attempt to connect via USB -> serial, the printer resets. It then runs through its' setup() routine. You will see the following:

Send: N0 M110 N0*125
Recv: Command not found!
Recv: echo: 3.7.0-2201
Recv: echo: Last Updated: Apr 19 2019 21:15:34 | Author: (none, default config)
Recv: Compiled: Apr 19 2019
Recv: echo: Free Memory: 1175 PlannerBufferBytes: 1392
Recv: echo:Stored settings retrieved
Recv: adc_init
Recv: CrashDetect DISABLED
Recv: PAT9125_init:0
Recv: FSensor DISABLED
Recv: 
Recv: echo:SD card ok
(Recv: MMU not responding - DISABLED) - if you did not disable MMU on compile

The setup routine ends there. You will see that it ignores the OctoPrint N0 M110 N0 request. OctoPrint will then timeout. It has nothing to do with Filament sensors, SD cards, MMUs. I'm not entirely sure why it manages to connect when manually doing so a second time.

The reason why baud rate AUTO works, is because of this setting:

OctoPrint Settings -> Serial Connection -> Intervals & timeouts -> Advanced options -> Initial baudrate detection pause -> 1s (default)

If you set this to 0, auto baudrate will fail.

There are a few ways to fix this:

1. Use the Auto baud rate workaround. However, it will fail if you compile your own firmware for custom baudrates.

2. Octoprint Settings -> Serial Connection -> Firmware & protocol -> Wait for start on connect (checked)

This works for stock Prusa FW (tested v3.7.0)

It will fail if you compile your own firmware for high baudrate.

3. Modify the Arduino setup() routine on the Prusa Firmware: https://github.com/prusa3d/Prusa-Firmware/commit/3320d7eb1ce1fbe25e5f0712b4ad799792893649

Essentially, make the printer reply 'ok' at the end of the setup() routine. It's probably undesirable, because it isn't truly acknowledging a command. However, it seems safe, since most programs (e.g. OctoPrint) are sensible enough not to send multiple Gcodes on printer initialisation.

RE: Octopi Connection Issue SOLVED

Posted by: shawn.b4

I just finished upgrading my prusa mk2s to mk2.5 and can't get it to connect to my Octopi.
I've been Googling & suspect that it has something to do with a "RPI PORT" setting but I can't find this setting in the LCD menus.
And can't find any documentation as to where/how to change this setting.
Help greatly appreciated.

SOLVED Update: the problem was apparently the latest firmware. I rolled back to 3.4.0 and connected right away.

I had issues with the filament sensor at 3.4.1 with white PLA(have not investigated issues so could be dirty sensor but only recently rebuilt so would be surprised). Leaving filament sensor disabled.

RE: Octopi Connection Issue SOLVED

Posted by: [email protected]

This is still an issue with the latest Prusa Firmware. I've been investigating this problem, and figured out the reason why octoprint fails on first connection.

When OctoPrint attempts to connect, you will see the following:

Send: N0 M110 N0*125

On successful connect, you will see this:

Recv: ok

With the current Prusa firmware (v3.7.0), on the very first attempt to connect via USB -> serial, the printer resets. It then runs through its' setup() routine. You will see the following:

Send: N0 M110 N0*125
Recv: Command not found!
Recv: echo: 3.7.0-2201
Recv: echo: Last Updated: Apr 19 2019 21:15:34 | Author: (none, default config)
Recv: Compiled: Apr 19 2019
Recv: echo: Free Memory: 1175 PlannerBufferBytes: 1392
Recv: echo:Stored settings retrieved
Recv: adc_init
Recv: CrashDetect DISABLED
Recv: PAT9125_init:0
Recv: FSensor DISABLED
Recv: 
Recv: echo:SD card ok
(Recv: MMU not responding - DISABLED) - if you did not disable MMU on compile

The setup routine ends there. You will see that it ignores the OctoPrint N0 M110 N0 request. OctoPrint will then timeout. It has nothing to do with Filament sensors, SD cards, MMUs. I'm not entirely sure why it manages to connect when manually doing so a second time.

The reason why baud rate AUTO works, is because of this setting:

OctoPrint Settings -> Serial Connection -> Intervals & timeouts -> Advanced options -> Initial baudrate detection pause -> 1s (default)

If you set this to 0, auto baudrate will fail.

There are a few ways to fix this:

1. Use the Auto baud rate workaround. However, it will fail if you compile your own firmware for custom baudrates.

2. Octoprint Settings -> Serial Connection -> Firmware & protocol -> Wait for start on connect (checked)

This works for stock Prusa FW (tested v3.7.0) Audacity Find My iPhone Origin

It will fail if you compile your own firmware for high baudrate.

3. Modify the Arduino setup() routine on the Prusa Firmware: https://github.com/prusa3d/Prusa-Firmware/commit/3320d7eb1ce1fbe25e5f0712b4ad799792893649

Essentially, make the printer reply 'ok' at the end of the setup() routine. It's probably undesirable, because it isn't truly acknowledging a command. However, it seems safe, since most programs (e.g. OctoPrint) are sensible enough not to send multiple Gcodes on printer initialisation.

 

 

 

 

I had issues with the filament sensor at 3.4.1 with white PLA(have not investigated issues so could be dirty sensor but only recently rebuilt so would be surprised). Leaving filament sensor disabled.