MMU not found

[Anubis1971]

• MK 3.5 (FW 6.0.0) + MMU3 (FW 3.0.3+896)
• Prusa MMU Plugin (2023.10.29)
• PrusaSlicer 2.7.4

Behaviors:

• MMU Not found in Octoprint

• Slicing single color with MMU3 profile works fine as long as extruder is selected before slicing. If extruder is set to default, MMU tries to load slot 0, regardless of the filament manager settings. Based on settings, a filament popup should appear allowing selection of slot #. And after 30 secs, MMU will default to whatever the filament select. However, nothing happens besides trying to load slot 0 continually.

• Slicing single color with regular 3.5 profile (non MMU), when print starts no filament is loaded and prints air. No filament select option is displayed when starting print.

Perhaps Octoprint not recognizing MMU3 is the problem. If not, then I believe when single color printing, the filament select should appear regardless of the profile used.

[jukebox42]

Hm interesting, I haven't tested with a 3.5 before (i've only got a 3s) so there may be something interesting in the firmware. You may be the first 3.X user to try this plugin :).

Would you be able to send me two logs from the octoprint terminal? They don't have to be complete I just want to see what commands are coming back, I might have to make some tweaks.

1. From when octoprint connects to the printer to after the MMU finishes it's initialization.
2. When the printer gets up to temp and starts a print.

Just to confirm:

• when slicing in single MMU mode does the filament selector popup show up?
• If yes, does selecting one from the list cause the MMU to select the correct line or does it always use 0?
• It sounds like my timeout filament selection may have a bug if it's defaulting to zero despite your selection.
• Do you have a custom startup script or are you using the default one?

Using a profile that does not include the MMU (your last test) is expected to fail and print air. Prusa expects you to manually feed the filament in if you slice without the MMU since the MMU won't receive any load commands from the gcode. I'm fairly certain the filament runoff sensor will malfunction in this case because it's expecting to be paired with the sensor on the MMU. To go back to printing without the MMU you need to remove the power connectors.

[Anubis1971]

Hopefully I am providing the correct logs which you are requesting.

1) Octoprint connected to Printer and MMU3 intialize Log 1 (Octoprint connect to 3.5 with MMU3).txt

2) Start print with 3.5 + MMU3 profile default extruder. With this condition, no filament popup and MMU3 tries to load slot 0. Log 2 (Sliced with 3.5 + MMU3 Profile - Default Extruder).txt

3) Start print with normal single extruder 3.5 profile. No filament selection popup. Prints starts but prints nothing since no filament is loaded. Log 3 (Sliced with Regular 3.5 Profile).txt

NOTE: If I do a "load to nozzle" #3 (from above) works fine. I prefer non MMU3 profile for single color because it's faster. Save time for longer prints.

To answer your questions:

• Popup does not occur with any printing condition
• I am not using any custom startup. Everything is stock.

Ideally, if MMU3 is present and default extruder used, a pop up should appear. Likewise, if single extruder profile is used and MMU3 is present a popup should also occur.

If I recall correctly, prior to upgrading to 3.5, the MK3S+ + MMU3 had a profile called MMU3 Single. When that profile was used, a pop would appear. Not sure what the difference is between those profiles, but it worked well.

[MysticGringo]

A similar situation exists on the MK4 and MMU3. Prusa has not included a "single mmu" profile. Prints made with the MK4/MMU3 profile work as expected. Prints with just MK4 profile don't trigger any action from Octoprint (no pop-up) nor the MMU and it does not load any filament, and prints air.

I can provide logs and more detail if needed.

[jukebox42]

Oh, that's interesting. I didn't realize they omitted the single mmu profile on the 3.X/4 models. I wonder if this means there's no single selection option being omitted. I just loaded some profiles in my slicer and i'm going to do some digging.

I'm not sure how i'm going to solve it yet. the popup shows because the printer sends a Tx when slicing with single mode. If the single mode doesnt exist I assume that means it's not sending a Tx

[jukebox42]

Alright I did some digging, it looks like they undid a lot of the support they added for the MMU3 from the MK3. It seems to resemble closer to what we used to get with the MMU2 in terms of reporting.

Would one of you be able to send me a successful load?

Looking at the second log, I can see the load being sent but it looks like it failed.

I'm hoping to see these three commands:

Recv: echo:MMU2:Feeding to FINDA
Recv: echo:MMU2:Feeding to extruder
Recv: echo:MMU2:Feeding to nozzle

followed by a:

Recv: echo:MMU2:Disengaging idler

[Anubis1971]

@jukebox42 Thank you for looking into this. Do you mean gcode which automatically loads filament? If so, the only way that works is if sliced with a specified extruder instead of using default. Will that log work for you?

[jukebox42]

Oh, yeah, I just want to see the Octoprint log when the mmu starts loading filament and succeeds. Doesn't matter what slice profile you use. I'm looking to see what it tells Octoprint so I know how to handle the state change. I found the code for it in their firmware I'm just not sure how much makes it to the serial connection.

This should help me fix the indicator. The single print popup is going to be a bit harder, it looks like they internalized that so I need to find another way to get at it.

[Kjubyte]

I did a small test print with one tool change in the middle: serial(1).log

I'm hoping to see these three commands:

Recv: echo:MMU2:Feeding to FINDA
Recv: echo:MMU2:Feeding to extruder
Recv: echo:MMU2:Feeding to nozzle

Almost correct, it's:

2024-04-27 19:36:34,768 - Send: N54 T0*11
2024-04-27 19:36:35,781 - Recv: echo:MMU2:Feeding to FINDA
2024-04-27 19:36:38,836 - Recv: echo:MMU2:Feeding to extruder
2024-04-27 19:36:40,894 - Recv: echo:MMU2:Feeding to FSensor
2024-04-27 19:36:44,142 - Recv: echo:MMU2:Disengaging idler
2024-04-27 19:36:45,158 - Recv: ResetRetryAttempts
2024-04-27 19:36:45,159 - Recv: echo:MMU2:CompensatedFeedDistance=50.0
2024-04-27 19:36:46,913 - Recv: ok

Change from t0 to t1:

2024-04-27 19:41:33,568 - Send: N1584 T1*3
2024-04-27 19:41:36,728 - Recv: echo:MMU2:Unloading to FINDA
2024-04-27 19:41:40,807 - Recv: echo:MMU2:Disengaging idler
2024-04-27 19:41:41,840 - Recv: echo:MMU2:Feeding to FINDA
2024-04-27 19:41:44,889 - Recv: echo:MMU2:Feeding to extruder
2024-04-27 19:41:46,931 - Recv: echo:MMU2:Feeding to FSensor
2024-04-27 19:41:50,130 - Recv: echo:MMU2:Disengaging idler
2024-04-27 19:41:51,150 - Recv: ResetRetryAttempts
2024-04-27 19:41:51,152 - Recv: echo:MMU2:CompensatedFeedDistance=50.0
2024-04-27 19:41:52,903 - Recv: ok

Unload at the end of the print:

2024-04-27 19:45:52,476 - Send: N3310 M702*23
2024-04-27 19:45:58,029 - Recv: X:241.00 Y:170.00 Z:40.00 E:-0.70 Count X:24100 Y:17000 Z:16000
2024-04-27 19:46:09,038 - Recv: echo:MMU2:Unloading to FINDA
2024-04-27 19:46:12,098 - Recv: echo:MMU2:Retract from FINDA
2024-04-27 19:46:13,116 - Recv: echo:MMU2:Disengaging idler
2024-04-27 19:46:14,136 - Recv: ResetRetryAttempts
2024-04-27 19:46:14,142 - Recv: echo:Hotend too cold
2024-04-27 19:46:14,143 - Recv: ok

[Anubis1971]

I think this log is another example of what you are looking for.
Log (3.5 + MMU3 Load Extruder 4).txt

How come Octoprint doesn't even recogize the MMU3?

[MysticGringo]

serial.txt

Here's a log from my MK4 and MMU3. I took this mid print. This has a few loads and unloads.

2024-04-28 07:42:23,025 - Recv: echo:MMU2:Feeding to FINDA 2024-04-28 07:42:25,057 - Recv: echo:MMU2:Feeding to extruder 2024-04-28 07:42:27,103 - Recv: echo:MMU2:Feeding to FSensor 2024-04-28 07:42:35,758 - Recv: echo:MMU2:Disengaging idler 2024-04-28 07:42:36,775 - Recv: echo:MMU2:CompensatedFeedDistance=50.0 2024-04-28 07:44:25,667 - Recv: echo:MMU2:Unloading to FINDA 2024-04-28 07:44:29,748 - Recv: echo:MMU2:Disengaging idler 2024-04-28 07:44:30,770 - Recv: echo:MMU2:Feeding to FINDA 2024-04-28 07:44:32,799 - Recv: echo:MMU2:Feeding to extruder 2024-04-28 07:44:35,868 - Recv: echo:MMU2:Feeding to FSensor 2024-04-28 07:44:44,163 - Recv: echo:MMU2:CompensatedFeedDistance=50.0 2024-04-28 07:50:04,246 - Recv: echo:MMU2:Unloading to FINDA 2024-04-28 07:50:08,330 - Recv: echo:MMU2:Disengaging idler 2024-04-28 07:50:09,346 - Recv: echo:MMU2:Feeding to FINDA 2024-04-28 07:50:11,381 - Recv: echo:MMU2:Feeding to extruder 2024-04-28 07:50:13,430 - Recv: echo:MMU2:Feeding to FSensor 2024-04-28 07:50:22,082 - Recv: echo:MMU2:Disengaging idler 2024-04-28 07:50:23,099 - Recv: echo:MMU2:CompensatedFeedDistance=50.0 2024-04-28 07:52:50,333 - Recv: echo:MMU2:Unloading to FINDA 2024-04-28 07:52:54,411 - Recv: echo:MMU2:Disengaging idler 2024-04-28 07:52:55,426 - Recv: echo:MMU2:Feeding to FINDA 2024-04-28 07:52:57,462 - Recv: echo:MMU2:Feeding to extruder 2024-04-28 07:53:00,525 - Recv: echo:MMU2:Feeding to FSensor 2024-04-28 07:53:08,869 - Recv: echo:MMU2:CompensatedFeedDistance=47.9

[jukebox42]

Thank you all, that was exactly what I was looking for, appreciate the help!

I'm starting a PR (#44) with the changes I need to make, it'll take me a few days to work through it (side project after all). Still working through how I'm going to handle single filament prints, I'm not seeing a tool command in that gcode but I'll keep digging. I should be able to have the mmu state detection done soon, but that's not really the best feature of this plugin.

I'll reach out when I need some testers :).

[jukebox42]

Hello All,

I'm wondering if I could solicit a few of you to test out a new version before I publish. I've tested already with my MK3 to make sure there are no regressions. Attached is the alpha build. I would love if I could get an MK3.5, MK3.9 and MK4 to try it out. If you are curious what is in the build check the PR link above, it's up to date.

This version should add the MMU status data back into the nav bar. I don't have the filament selection modal figured out yet but gotta start somewhere :).

If you'd like to test:

• Install the build attached to this message, you can do that by going into your plugins list, clicking add, scrolling to the bottom and using the install to upload the zip file.
• It'll have you restart octoprint (ignore it when it tells you there's a new version of my plugin available)
• Open the plugin settings, scroll to Advanced and turn on debug mode
• Open your browser's dev tools and go to Console (we want to see the logs)
• Connect your printer (if you are already connected, disconnecting and re-connecting)
• You are looking for this debug log, it tells you what version the plugin thinks your printer is. Please share it.
• If the log matches your printer please try a multi filament print. I've attached a zip with a 3mf file if you want a quick print that draws 3 lines (sorry for the zip, github won't accept a 3mf).
• Verify it shows the MMU as connected and you see the filament load/unload in the nav. You will also see them duplicated in the dev tools as logs
• Please share your findings, bonus if you can send me your console logs from dev tools.

Assuming this one works as expected I'll get it out so you all at least have that feature working while I figure the rest out.

Thank you in advance!

Octoprint-PrusaMmu.zip 3-lines.zip

[jshank]

EDIT: First, a huge thank you for providing this plugin. I've been grudgingly using PrusaConnect since upgrading to the MMU3 and this gives me hope that I'll be able to come back to Octoprint. I wasn't able to get to the point of printing the test files due to loss of connectivity. Hopefully my logs are useful. LMK if you need any other debugging.

From devtools

{
    "action": "debug",
    "msg": "firmware_info_hook: MK4 {\"FIRMWARE_NAME\": \"Prusa-Firmware-Buddy 6.0.0+14794 (Github)\", \"SOURCE_CODE_URL\": \"https://github.com/prusa3d/Prusa-Firmware-Buddy\", \"PROTOCOL_VERSION\": \"1.0\", \"MACHINE_TYPE\": \"Prusa-MK4\", \"EXTRUDER_COUNT\": \"1\", \"UUID\": \"REDACTED\"}"
}

I lose connection within a few seconds of connecting. Disabling the plugin resolves the issue and I can connect via serial again.

Changing monitoring state from "Offline" to "Detecting serial connection"
Performing autodetection with 1 port/baudrate candidates: /dev/ttyACM0@115200
Trying port /dev/ttyACM0, baudrate 115200
Connecting to port /dev/ttyACM0, baudrate 115200
Handshake attempt #1 with timeout 2.0s
Connected to: Serial<id=0x677e6a90, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Send: N0 M110 N0*125
Recv: ok
Changing monitoring state from "Detecting serial connection" to "Operational"
Send: N0 M110 N0*125
Recv: ok
Send: N1 M115*39
Recv: FIRMWARE_NAME:Prusa-Firmware-Buddy 6.0.0+14794 (Github) SOURCE_CODE_URL:https://github.com/prusa3d/Prusa-Firmware-Buddy PROTOCOL_VERSION:1.0 MACHINE_TYPE:Prusa-MK4 EXTRUDER_COUNT:1 UUID:REDACTED
Recv: Cap:SERIAL_XON_XOFF:0
Recv: Cap:BINARY_FILE_TRANSFER:0
Recv: Cap:EEPROM:0
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:AUTOLEVEL:1
Recv: Cap:Z_PROBE:1
Recv: Cap:LEVELING_DATA:1
Recv: Cap:BUILD_PERCENT:0
Recv: Cap:SOFTWARE_POWER:1
Recv: Cap:TOGGLE_LIGHTS:0
Recv: Cap:CASE_LIGHT_BRIGHTNESS:0
Recv: Cap:EMERGENCY_PARSER:0
Recv: Cap:PROMPT_SUPPORT:0
Recv: Cap:AUTOREPORT_SD_STATUS:0
Recv: Cap:THERMAL_PROTECTION:1
Recv: Cap:MOTION_MODES:0
Recv: Cap:CHAMBER_TEMPERATURE:0
Recv: ok
Recv: RSTCommTimeout
Recv: RSTCommTimeout
Recv: RSTCommTimeout
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: M21
Recv: ok
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: M105
Recv: ok T:19.00/0.00 B:20.42/0.00 X:20.06/36.00 A:29.48/0.00 @:0 B@:0 HBR@:0
No response from printer after 3 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Changing monitoring state from "Operational" to "Offline after error"
Connection closed, closing down monitor

Once MMU plugin is disabled:

Performing autodetection with 1 port/baudrate candidates: /dev/ttyACM0@115200
Trying port /dev/ttyACM0, baudrate 115200
Connecting to port /dev/ttyACM0, baudrate 115200
Handshake attempt #1 with timeout 2.0s
Connected to: Serial<id=0x6b2fa8d0, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Send: N0 M110 N0*125
Recv: ok
Changing monitoring state from "Detecting serial connection" to "Operational"
Send: N0 M110 N0*125
Recv: ok
Send: N1 M115*39
Recv: FIRMWARE_NAME:Prusa-Firmware-Buddy 6.0.0+14794 (Github) SOURCE_CODE_URL:https://github.com/prusa3d/Prusa-Firmware-Buddy PROTOCOL_VERSION:1.0 MACHINE_TYPE:Prusa-MK4 EXTRUDER_COUNT:1 UUID:REDACTED
Recv: Cap:SERIAL_XON_XOFF:0
Recv: Cap:BINARY_FILE_TRANSFER:0
Recv: Cap:EEPROM:0
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:AUTOLEVEL:1
Recv: Cap:Z_PROBE:1
Recv: Cap:LEVELING_DATA:1
Recv: Cap:BUILD_PERCENT:0
Recv: Cap:SOFTWARE_POWER:1
Recv: Cap:TOGGLE_LIGHTS:0
Recv: Cap:CASE_LIGHT_BRIGHTNESS:0
Recv: Cap:EMERGENCY_PARSER:0
Recv: Cap:PROMPT_SUPPORT:0
Recv: Cap:AUTOREPORT_SD_STATUS:0
Recv: Cap:THERMAL_PROTECTION:1
Recv: Cap:MOTION_MODES:0
Recv: Cap:CHAMBER_TEMPERATURE:0
Recv: ok
Send: M21
Recv: ok
Send: M155 S2
Recv: ok
Recv:  T:19.00/0.00 B:20.33/0.00 X:19.88/36.00 A:27.53/0.00 @:0 B@:0 HBR@:0
Send: M20
Recv: Begin file list
--SNIP--
Recv: End file list
Recv: ok
Recv:  T:19.00/0.00 B:20.24/0.00 X:19.93/36.00 A:27.58/0.00 @:0 B@:0 HBR@:0
Recv:  T:19.00/0.00 B:20.24/0.00 X:19.90/36.00 A:27.76/0.00 @:0 B@:0 HBR@:0

[MysticGringo]

Yep, I get a "crash" every time I try to connect to the printer. The top bar says MMU Needs attention, unknown error. and directs me to: https://help.prusa3d.com/article/unknown-error-04900-mmu_484853

The display shows something about unloading filament manually with a retry button that doesn't do anything.

Disabling the plugin makes everything work again.

MK4 (6.0.0 - RC1), MMU3 (3.0.3), Octoprint (1.9.3)

[jukebox42]

Huh, well that's unsettling. Could either of you look in your octoprint.log and see if there's a python error in there? I don't do any manipulation during a connection, I just read the metadata

[MysticGringo]

Maybe this (I am in design and construction, not coding, so not sure if this is helpful):

2024-05-13 17:18:40,725 - octoprint.util.comm - ERROR - Unexpected error while reading from serial port Traceback (most recent call last): File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/util/comm.py", line 4081, in _readline ret = self._serial.readline() File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/util/comm.py", line 6832, in readline c = self.read(1) File "/home/pi/oprint/lib/python3.9/site-packages/serial/serialposix.py", line 595, in read raise SerialException( serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

That may be from a different error? After this print, I flush the log, turn on the plugin and restart everything to see what happens, and include the log here.

[jshank]

Octoprint Version 1.10.0 OctoPi Version 0.18.0, running on Raspberry Pi 3 Model B Rev 1.2

No python errors related to MMU in octoprint.log. I did find some python errors relating to the bgcode plugin. I used pip to remove it (another problem for another day) but it didn't change anything with the disconnects from MMU plugin.

Do I need to disable PrusaLink/PrusaConnect integrations?

octoprint.log

2024-05-13 15:51:28,281 - octoprint.plugins.tracking - INFO - Sent tracking event webui_load, payload: {'browser_name': 'Chrome', 'browser_version': '125.0.0.0', 'os_name': 'Mac OS', 'os_version': '10.15.7'}
2024-05-13 15:51:37,054 - octoprint.plugins.psucontrol - INFO - Switching PSU On
2024-05-13 15:51:37,568 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Detecting serial connection"
2024-05-13 15:51:37,618 - octoprint.util.comm - INFO - Serial detection: Performing autodetection with 0 port/baudrate candidates: 
2024-05-13 15:51:37,619 - octoprint.util.comm - INFO - Changing monitoring state from "Detecting serial connection" to "Error"
2024-05-13 15:51:37,631 - octoprint.util.comm - INFO - Changing monitoring state from "Error" to "Offline after error"
2024-05-13 15:51:37,673 - octoprint.plugins.enclosure - INFO - Detected Error in PrinterStateChanged id: ERROR state: Error  will call listeners for shutdown_on_error!
2024-05-13 15:51:37,807 - octoprint.plugins.enclosure - INFO - Detected Error or Disconnect in Error will call listeners for shutdown_on_error!
2024-05-13 15:51:37,918 - octoprint.server - INFO - Autorefresh of serial port list stopped
2024-05-13 15:51:37,924 - octoprint.server - INFO - Starting autorefresh of serial port list
2024-05-13 15:51:37,943 - octoprint.plugins.action_command_notification - INFO - Notifications cleared
2024-05-13 15:51:37,954 - octoprint.plugins.enclosure - INFO - Detected Error or Disconnect in Disconnected will call listeners for shutdown_on_error!
2024-05-13 15:51:38,545 - octoprint.plugins.tracking - INFO - Sent tracking event commerror_autodetect, payload: {'commerror_text': 'No more candidates to test, and no working port/baudrate combination detected.'}
2024-05-13 15:51:49,169 - octoprint.server - INFO - Serial port list was updated, refreshing the port list in the frontend
2024-05-13 15:51:56,645 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Detecting serial connection"
2024-05-13 15:51:56,742 - octoprint.util.comm - INFO - Serial detection: Performing autodetection with 1 port/baudrate candidates: /dev/ttyACM0@115200
2024-05-13 15:51:56,742 - octoprint.util.comm - INFO - Serial detection: Trying port /dev/ttyACM0, baudrate 115200
2024-05-13 15:51:56,746 - octoprint.util.comm - INFO - Connecting to port /dev/ttyACM0, baudrate 115200
2024-05-13 15:51:56,792 - octoprint.util.comm - INFO - Serial detection: Handshake attempt #1 with timeout 2.0s
2024-05-13 15:51:56,811 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2024-05-13 15:51:56,902 - octoprint.util.comm - INFO - Changing monitoring state from "Detecting serial connection" to "Operational"
2024-05-13 15:51:56,924 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2024-05-13 15:51:56,987 - octoprint.util.comm - INFO - Printer reports firmware name "Prusa-Firmware-Buddy 6.0.0+14794 (Github)"
2024-05-13 15:51:56,987 - octoprint.util.comm - INFO - Firmware info line: FIRMWARE_NAME:Prusa-Firmware-Buddy 6.0.0+14794 (Github) SOURCE_CODE_URL:https://github.com/prusa3d/Prusa-Firmware-Buddy PROTOCOL_VERSION:1.0 MACHINE_TYPE:Prusa-MK4 EXTRUDER_COUNT:1 UUID:REDACTED
2024-05-13 15:51:56,987 - octoprint.util.comm - INFO - Detected Prusa firmware, enabling relevant features for issue free communication
2024-05-13 15:51:57,251 - octoprint.plugins.firmwareupdater - INFO - Got CONNECTED event
2024-05-13 15:51:57,282 - octoprint.plugins.firmwareupdater - INFO - Run postflash flag is not set
2024-05-13 15:51:57,303 - octoprint.server - INFO - Autorefresh of serial port list stopped
2024-05-13 15:51:58,279 - octoprint.plugins.tracking - INFO - Sent tracking event printer_connected, payload: {'firmware_name': 'Prusa-Firmware-Buddy 6.0.0+14794 (Github)', 'printer_port': 'AUTO', 'printer_baudrate': 115200}
--SNIP camera detection--
2024-05-13 15:52:28,301 - octoprint.util.comm - INFO - Communication timeout while idle, trying to trigger response from printer.
2024-05-13 15:52:28,320 - octoprint.util.comm - INFO - Communication timeout while idle, trying to trigger response from printer.
2024-05-13 15:52:28,336 - octoprint.util.comm - INFO - No response from printer after 3 consecutive communication timeouts, considering it dead.
2024-05-13 15:52:28,364 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Offline after error"
2024-05-13 15:52:28,430 - octoprint.plugins.enclosure - INFO - Detected Error or Disconnect in Error will call listeners for shutdown_on_error!
2024-05-13 15:52:28,540 - octoprint.server - INFO - Starting autorefresh of serial port list
2024-05-13 15:52:28,551 - octoprint.plugins.action_command_notification - INFO - Notifications cleared
2024-05-13 15:52:28,562 - octoprint.plugins.enclosure - INFO - Detected Error or Disconnect in Disconnected will call listeners for shutdown_on_error!

[MysticGringo]

octoprint-5.log

This morning I deleted the log, rebooted Octoprint with plugin disabled. Enabled the MMU plugin, and restarted octoprint. I would not connect to the printer. I pushed the button to connect, it did not. I turned off the plugin, restarted octoprint, and it connected.

This log should only contain this info. Hopefully it ill help you narrow down where the issue is.

[Anubis1971]

octoprint-5.log

This morning I deleted the log, rebooted Octoprint with plugin disabled. Enabled the MMU plugin, and restarted octoprint. I would not connect to the printer. I pushed the button to connect, it did not. I turned off the plugin, restarted octoprint, and it connected.

Tried the plugin last night as well. Experienced the same issues as MysticGringo. Thanks for working on this.

[jshank]

What's really strange is that I can clearly see the responses from the printer. Is there any chance you're "intercepting" the responses and the comm routine doesn't see them?

[AaronVARC]

Just to add in here.... I am using a mk3.5 with the MMU3. I cranked up the logs to debug level and noticed this on startup: 2024-05-16 19:46:34,850 - octoprint.plugin.core - ERROR - Error loading plugin prusammu Traceback (most recent call last): File "/home/aaron/oprint/lib/python3.9/site-packages/octoprint/plugin/core.py", line 1297, in _import_plugin module = _load_module(module_name, spec) File "/home/aaron/oprint/lib/python3.9/site-packages/octoprint/plugin/core.py", line 52, in _load_module return imp.load_module(name, f, filename, details) File "/home/aaron/oprint/lib/python3.9/site-packages/octoprint/vendor/imp.py", line 238, in load_module return load_package(name, filename) File "/home/aaron/oprint/lib/python3.9/site-packages/octoprint/vendor/imp.py", line 210, in load_package return _exec(spec, sys.modules[name]) File "", line 613, in _exec File "", line 790, in exec_module File "", line 228, in _call_with_frames_removed File "/home/aaron/oprint/lib/python3.9/site-packages/octoprint_prusammu/init.py", line 12, in from octoprint_prusammu.common.Mmu import MmuStates, MmuKeys, MMU3Codes, \ ImportError: cannot import name 'MMU3MK4Commands' from 'octoprint_prusammu.common.Mmu' (/home/aaron/oprint/lib/python3.9/site-packages/octoprint_prusammu/common/Mmu.py)

looks like there may be an import error that's causing the loop? My MK3.5 doesn't really crash per se but I can't complete the connection using octopi. It eventually times out with the error:

State: Offline after error Too many consecutive timeouts, printer still connected and alive?

Hope this helps. I may poke around the code as well and see if I see anything easy that may help.

[jukebox42]

These logs helped, thanks all. Was a silly mistake 🤦. I was silencing all gcode lines if they weren't they ones I was looking for when it detected one of the new MKs. What I get for flying blind. I'm going to try to make the VirtualPrinter pretend to be an MK4 to do some additional digging before I subject you all to another experiment.

@AaronVARC That's an interesting error, looks like it had trouble installing, I double checked and the files were all included in the zip. Hopefully the next one helps.

[jukebox42]

Alright, I think I've got a version that should hopefully work. It's hard to simulate the MMU during printing so it may not report correctly.

I'd love another test when folks have time, this one shouldn't cause connection issues.

This should work with a multi color print and show the MMU state changes. No need to enable debug mode or check for the firmware line (unless it's not telling you the MMU is present. Still no single print support yet.

Thank you in advance!

Octoprint-PrusaMmu.zip

[AaronVARC]

This update works great now. No error messages like I saw in the last build and everything connects great. I can see the status as it's loading the filament (including the intermediate steps) but once the printer is loaded and starts printing with a tool it looks like it misses the last message as the navbar gets stuck on the following message instead of showing the tool in use like the old one did:

I quit out of the print so not sure what happens on the next tool change but progress for sure.

[jukebox42]

Thank @AaronVARC for the quick test. 🤞 I've fixed the detection for the end of loading.

If anyone could please test the one below.

It would be really helpful if you could post your Octoprint Terminal in the event a state change didnt detect properly. It's going to be a little like whack-a-mole making sure the right states are being sent back (prusa has a lot more than they use in their array)

Octoprint-PrusaMmu.zip

[AaronVARC]

That got it. It shows the filament now when it is printing after it's loaded successfully. Here's the serial.log for the three line print 3mf you included above. One thing is that when you restart octopi it shows the MMU as not found until a print starts and the first gcode intercept happens. This blocks changing any settings in the plugin as it doesn't think there is an MMU there.

serial.log

[MysticGringo]

Yep, this seems to be working as expected. Looking forward to selecting the material for the print when you can figure it out. It's a shame Prusa changed so much and took away some of the user adaptability.

[AaronVARC]

So I dug into the new buddy gcode a bit and played around with it this morning. It looks like M1600 may be a start. When you start a single tool print on the 3.5 it pops up a menu on the LCD to select which tool to use, which is a front end for this M1600 command. It looks like M1600 done before the print basically allows configuration as if you are selecting on this menu and then bypasses the pause on the printer. I did a quick test and was able to get it to load a specific tool just by using the M1600. It doesn't look like there is a comparable command on the MK3s but I don't have one anymore so can't really monitor it the same way.

https://help.prusa3d.com/article/buddy-firmware-specific-g-code-commands_633112

Also just from a user experience standpoint may want to think about changing the "not found" to something like "unknown" as I can imagine users thinking it's broken and not working and going bonkers with tickets.

[Anubis1971]

Installed the lastest version. My MMU still shows not found. Here is the console log:

Disconnected and connected several times and still no connection to MMU.

[jukebox42]

@AaronVARC now that's an interesting idea. When you have a sec, can you please test this build. I want to see if the M1600 is sent to octoprint (assuming it calls M1600 on print start). You'll need to turn debug back on in the plugin and watch the devtools console.

When you start a single print I'm hoping you see WE SAW AN M1600: {} in the log. If you do we might be able to hijack it and replace it.

I'd love if you can start a single print and select a tool. If even one comes back I've got a plan...

This build should also hopefully fix the MMU detection. And I swapped "Not Found" to "Unknown". Good suggestion.

Octoprint-PrusaMmu.zip

As always, thank you all for helping me with this.

[AaronVARC]

So the single print from octoprint is super derpy. I can get the M1600 to work when you direct print from USB but when I try a single print from octoprint it's kind of all over the place.

There is no M1600 command issued and in fact, it doesn't even check if there is a filament loaded. It will just start executing the gcode without anything loaded like the print is going off as normal. If there is filament still loaded from a prior print it will just use that material regardless of type/color etc. I've tried manually pushing in the M1600 prior to starting the print but it doesn't seem to do anything. I did notice that under controls I now have a tool option and can choose 0-4. See the pic:

When I do this it doesn't give me any feedback but when I go to print the printer does load the filament selected and starts the print. There seems to be some loading command missing (I think it's extruder to hotend that last inch or so) because nothing actually comes out but I'll keep playing with it and see if I can sort through how to make it work. I did a bit of monitoring when using the dropdown and noticed it was just sending a simple Tx command as decribed here:

https://help.prusa3d.com/article/prusa-firmware-specific-g-code-commands_112173#t-codes

I'll keep digging but as long as you can grab and block before the print starts I think a Tx command and some type of load command could get it there.

[TangoOversway]

I'm trying to absorb all that's discussed here.

I have a Prusa Mk3.5 and just installed an MMU3. I have OctoPi running on a Pi Zero 2W and I keep it up to date. (Version is OctoPi build 2023.10.09.151442.) I installed this plugin, but it does not see my MMU. I do see some zip files from @jukebox42 for download. Are these later than the current plugin version I get from a "normal" plugin install on OctoPrint?

And will any logs or info from my system help with any work on this?

[jukebox42]

Hey, All; thanks for your patience. Getting back to this now.

Don't get your hopes too far up about my latest release. It fixes the MMU detection for MK3.5+ but it still doesn't fix the popup for single filament print.

Prusa made this really hard to do reliably. I'm going to start another PR for that support. I still want to do something there. I'm going to see if I can catch the initial print button press and pause there. then make use of overwriting filament that @BlueFyre recommended.

[jukebox42]

Alright, I've got something I'd love for someone to test. I've tested as much as I can with my MK3 but since the MK3 doesn't recognize the M863 command I couldn't test the actual feature.

If you are curious what's in this release you can view the source here #49.

The general idea is that for MK3.5+ you will always use the MMU3 slice mode and never the base profile. The popup will show offering you to pick a color, and will have a new "Skip" option. Selecting a color will cause ALL tool changes to be re-mapped to that tool. Selecting Skip will have it print like normal (whatever tool the print has, it will use).

It makes use of M863. When you select a color I send M863 E1 (to enable). Then for every tool not selected it sends a M863 P# L# to overwrite to that selected tool. On print start and end I reset (M863 R) to avoid preserving the previous choice.

It will probably show the wrong color in the header, I'm expecting it to and can fix that if this test works.

Please try this with a multi-filament print first. We want to make sure it replaces all of them

Here's what I'd like to know:

• Please turn on debug to test and open your browser's dev tools
• Please also navigate to the terminal view in octoprint to see your printer's response
• When you get the menu, and select can you verify your printer does not reject the M863 commands? Can you verify they all get sent?
• Can you look in the browser dev tools for an _enable_m863_mode debug call and share it here?
• Verify the printer only prints with the filament you picked and not the other ones.
• Can you check for any octoprint python errors in your octoprint.log?

I've attached a version you can test with below and a zip file with an stl to test with (the smallest test i can make)

If you have any issues you should be able to send M863 E0 to your printer to disable the rewrite mode.

Thank you all for the help!

Octoprint-PrusaMmu.zip 3-lines.zip

[MysticGringo]

Hey Jukebox...

I've tested this, and it appears to work as you intended. I did my own file to test (I use PETG 99% of time and single little lines are impossible to get off the bed. It gave me the select filament. I am on an MK4 with latest firmware. It did print with the correct colors chosen (1,2,5 in my case).

Attached is also a PDF of the terminal log that the printer puts out (on a Mac so it wants to PDF everything). I can't find the _enable_m863_mode debug call... maybe I don't know how to find it. I'll keep trying. MMU-Test.pdf

I did try it with a single color print (sliced as regular MK4 without MMU, so no filament chosen in slicer) and it did not engage the MMU, just printed with no filament loaded.

Thank you again for all your work!

[MysticGringo]

As an update, I started a single color print that I had chosen filament 5 in the slicer, and told it to skip when the plugin prompted me to select the color... it started printing with filament 4. Not sure what that's about, but thought that info might be handy.

[jukebox42]

Awesome, thanks for the quick test! When it printed the wrong filament. Did you choose 4 the previous print? I'm curious if I'm not resetting the override properly.

The info is helpful. I should be able to pick this back up this weekend.

On Wed, Jul 3, 2024, 4:07 PM MysticGringo @.***> wrote:

As an update, I started a single color print that I had chosen filament 5 in the slicer, and told it to skip when the plugin prompted me to select the color... it started printing with filament 4. Not sure what that's about, but thought that info might be handy.

— Reply to this email directly, view it on GitHub https://github.com/jukebox42/Octoprint-PrusaMMU/issues/43#issuecomment-2207144114, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE73ZEMN3C7LRYCD77LDLLZKRKW7AVCNFSM6AAAAABGQ6ZSAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBXGE2DIMJRGQ . You are receiving this because you were mentioned.Message ID: @.***>

[MysticGringo]

Nope... 4 was not used for the previous print, nor was it used in any multi-material print. I printed the same thing again, and this time told it to use 5... and it still loaded 4. Hope that helps, and thank you again.

[jukebox42]

Hmm, I may have found that bug. Here is a new version. Skip should be working as expected now. I think I was sending an indeterminate state on skip because I was missing a return. To be safe, I also disabled remapping at the start and end now in case the reset isn't doing what we expect.

When you have a second, please test this build: Octoprint-PrusaMmu.zip

Tests that would be helpful:

• One print where you use the modal to select a tool not found in the sliced file and confirm it prints only with that tool (preferably a multi-tool print)
• One print where you select "Skip" and it prints the correctly sliced tool (preferably a multi-tool print)

Reminder: Slicing without the MMU profile won't work. There's no way for me to catch that behavior anymore.

Thanks in advance!

[MysticGringo]

Thanks Jukebox...

I tried the new version this morning, MK4, MMU3. The skip now works as intended... I tried one sliced with a single color, and one using 2 colors, both worked as intended.

Using the modal (choosing the color) does not work however, and sends the printer into an error. Bright red screen that says:

"PrusaToolChanger Toolchange to tool that is disabled by tool mapping."

I tried slicing by picking a particular tool, and one by leaving the slice on "default" (which I presume just picks tool #1).

It's going to be a real bummer if Prusa has messed this up for good, I used your plugin all the time as when I slice a file, I might change the roll colors around by time I print it.

Thanks for your efforts.

[jukebox42]

Thanks @MysticGringo that may have been because I tried to replace the tool with the same tool. I figured it'd be safe. Here's a quick change to avoid that. 🤞. If you could run a filament select test with this build I'd appreciate it. Thank you for all your testing! Octoprint-PrusaMmu.zip

[MysticGringo]

Hey, tried the new version, it did not give a warning, but it did not print with the tool I selected, instead it printed with the tool that was sliced. I sliced it for tool 5, but selected tool 3 with your plugin and it printed with tool 5. Also, it showed "MMU Unknown", but that might be because I think it does that after a restart of octoprint (which was needed after loading new plugin), and not a big deal for me at this time.

Thanks again.

[MysticGringo]

One more thing... the status is now showing "MMU Idle" all the time. It shows MMU Unknown after a reboot or restart of Octoprint, Idle all other times. Not a big deal to me, but thought I'd let you know.

[jukebox42]

Been doing some deeper digging into the tool mapping source, trying to figure out how it works. Looks like multi tool should stay enabled so I made an update for that.

https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/master/lib/Marlin/Marlin/src/module/prusa/tool_mapper.cpp

Everything I'm seeing makes me think what we're doing should work.

@MysticGringo When you test again, after you select filament and the printer is warming up. Can you send an M863 in the code terminal? Without any additional characters it should send you back how the tools are mapped in the terminal. I'd like to see how it thinks it's mapping.

Octoprint-PrusaMmu.zip

[MysticGringo]

So I tried this new one. Object sliced with tool 5, but I selected tool 4 with the plugin... it printed with tool 5.

I sent the M863, here's the response:

Recv: ok Send: N43 M863*25 Recv: Tool mapping: Recv: Tool 0 -> Recv: Tool 1 -> Recv: Tool 2 -> Recv: Tool 3 -> 4 Recv: Tool 4 -> Recv: Enabled: 0 Recv: ok

It actually says Tool 0 -> none, but GitHub is reading it as code I guess. I sent it again during the print and same results. Not sure why it printed with tool 5, when it appears it should be printing with 4.

To alleviate confusion (probably just my confusion) I did the same and selected tool 1, it printed with tool 5 (which was what it was sliced for). Here's the M863 response:

Recv: ok Send: N44 M863*30 Recv: Tool mapping: Recv: Tool 0 -> 4 Recv: Tool 1 -> Recv: Tool 2 -> Recv: Tool 3 -> Recv: Tool 4 -> Recv: Enabled: 0 Recv: ok

Hope this helps.

[jukebox42]

Huh, this tells me the mapping code probably works in reverse instead of the way I've been interpreting it.

🤞 this was exactly what we needed. Here's an updated version to try. Thanks in advance!

Octoprint-PrusaMmu.zip

[MysticGringo]

Well... I tired the same print. It's sliced with tool 5, but I chose tool 1 with the plugin... it still printed with 5.

Here's the M863 response:

Send: N373 M863*41 Recv: Tool mapping: Recv: Tool 0 -> <none Recv: Tool 1 -> <none Recv: Tool 2 -> <none Recv: Tool 3 -> <none Recv: Tool 4 -> 0 Recv: Enabled: 0 Recv: ok

So that looks right... buuuuut... still printed with tool 5. (I removed the ">" from the none's incase seeing the "none" helps in anyway).

Thanks for all your work, I am certainly not the only one who appreciates it.

[jukebox42]

Hmmm, still noodling on this one. I really thought we were on to something. I'll dig deeper into the remapping stuff. There's got to be something I'm missing.

[jukebox42]

Alright, Here's an attempt at brute forcing the rewrite for the MK4s. I'm manually overwriting the tool command with the one you selected.

If this fails, I suspect I'm going to need to find a way to have you select the filament to print with before you select the print.

Thank you in advance! Appreciate the patience as I find time to work on this.

Octoprint-PrusaMmu.zip

[MysticGringo]

Thanks for continuing to try. Unfortunately this one didn't work either. Object sliced with tool 1, told to print with tool 3, but it printed with 1. Also, it still shows MMU: Idle the whole time.

I appreciate your efforts with this, it has to be annoying.

Recv: ok Send: N47 M863*29 Recv: Tool mapping: Recv: Tool 0 -> 0 Recv: Tool 1 -> 1 Recv: Tool 2 -> 2 Recv: Tool 3 -> 3 Recv: Tool 4 -> 4 Recv: Enabled: 0 Recv: ok