[BUG] MK3SMMU2S "G-code sliced for a different printer type. Continue?"

[clintonefisher]

Printer model

MK3S/+

MMU model

MMU2S

Firmware versions

3.14.0 and 3.0.2

Upgrades and modifications

No response

Printing from...

SD Card

Describe the bug

I just upgraded my MK3S to 3.14.0 and MMU2 to 3.0.2, from the binaries in: prusa3d_fw_3_14_0_MK3S_3_0_2_MMU2S.zip
(Downloaded from https://help.prusa3d.com/downloads)

Now, when slicing with the , I get the error: "G-code sliced for a different printer type, continue?"

M862.3 Q returns MK3SMMU3, where it should be MK3SMMU2S

Even the USB serial log shows messages coming from MMU2.

I don't really want to fake it and choose the MK3SMMU3 profile because I do not own an MMU3.
I own a MMU2S.

How to reproduce

Upgrade MK3S firmware to 3.14.0 and MMU2S from 3.0.0 to 3.0.2 - as is required by 3.14.0.
Slice a file using the "Original Prusa i3 MK3S & MK3S+ MMU2S" profile.
Print the file (from SD card)
Printer reports: "G-code sliced for a different printer type. Continue?"

Expected behavior

No response

Files

No response

[3d-gussner]

@clintonefisher Thanks for the report.

Even the USB serial log shows messages coming from MMU2.

The MMU2 in the serial output is just an indicator for MMU communication. The firmware doesn't know if the hardware and electronics are MMU2, MMU2S or MMU3 parts.

You can change the GCode check to ignore it, but I would advise to use the MK3S+MMU3 Prusa Slicer profile as it is "identical" to the MK3S+MMU2S profile in PrusaSlicer see here

[clintonefisher]

@clintonefisher Thanks for the report.

Even the USB serial log shows messages coming from MMU2.

The MMU2 in the serial output is just an indicator for MMU communication. The firmware doesn't know if the hardware and electronics are MMU2, MMU2S or MMU3 parts.

You can change the GCode check to ignore it, but I would advise to use the MK3S+MMU3 Prusa Slicer profile as it is "identical" to the MK3S+MMU2S profile in PrusaSlicer see here

@3d-gussner thanks for the response and the workaround. I'll just use the MK3S+MMU3 profile for now.

As trivial as it is, it would be great to see this fixed - mainly because it generates unnecessary concern after this firmware upgrade, and there has been no official announcement that MMU3 and MMU2S have merged, etc, that would tell printer users to use the MMU3 profile.
My only hope would be to save others the time I just spent. :)

In any case, I very much appreciate all of your and others' work on building and maintaining this.
The new MMU2S functionality and behavior is great. Way better than before 3.0.0!
One of the things that keeps Prusa great is the support of existing products.
I am grateful for that.
Cheers!

[clintonefisher]

@clintonefisher Thanks for the report.

Even the USB serial log shows messages coming from MMU2.

The MMU2 in the serial output is just an indicator for MMU communication. The firmware doesn't know if the hardware and electronics are MMU2, MMU2S or MMU3 parts.

You can change the GCode check to ignore it, but I would advise to use the MK3S+MMU3 Prusa Slicer profile as it is "identical" to the MK3S+MMU2S profile in PrusaSlicer see here

@3d-gussner I just realized that all of my previous slices are going to throw this error because they were sliced (correctly) for MK3SMMU2S. This will drive me crazy and I cannot imagine any other MMU2S owner being happy about it.

There must be a way to update the 3.14.0 firmware to correctly recognize it has a MMU2S connected instead of a MMU3, and report the correct model printer and also pass the printer check. I really don't want to disable the printer check - I have more than one printer, and this is a useful feature.

[3d-gussner]

There must be a way to update the 3.14.0 firmware to correctly recognize it has a MMU2S connected instead of a MMU3, and report the correct model printer and also pass the printer check.

One way would be to have two MMU firmware files that report the "hardware" version. As said the MMU firmware cannot detect which plastic and hardware parts are used.

• The whole idea of MMU2S to MMU3 upgrade was/is to reduce the amount of new hardware, electronics to a minimum and improve the plastic parts, so upgrade kits are as affordable as possible.
• There have been many improvements made to even make MK2.5/S + MMU2S working with the new firmware. Give the community access to adjust several settings to fine tune to the reported needs.

This would mean users would need to flash the MMU2S firmware or the MMU3 firmware.
This will cause other issues as users may flash the wrong firmware or at some point switch to MK3S + MMU3 profiles and complain again.

You can also modify your sliced MMU gcode files and change only the M862.3 P line.
If you do that please use a good editor like notepad++.

I am sorry but we will not try to attempt to somehow implement a workaround in the firmwares as it would use way to many resources.

In any case, I very much appreciate all of your and others' work on building and maintaining this.

Thanks for the nice words, very appreciated. 🤗

[clintonefisher]

I am sorry but we will not try to attempt to somehow implement a workaround in the firmwares as it would use way to many resources.

@3d-gussner Oof. This hurts to hear.
One of the things that has made Prusa so great is the ongoing support of older platforms. Customers know they won't be abandoned the moment a new major version is released. And this philosophy has held strong for many years.

The improvements to MMU2S are fantastic and took something that was very fiddly and made it actually usable. For that I am extremely grateful.

I understand that maintaining separate firmwares would use more resources, but what about the resources of all the existing MMU2S customers who are excited about the new 3.14.0/3.0.2 firmwares, but then realize - only after upgrading, that they either have to disable the useful printer check feature, or re-slice older files, or just ignore the warnings, which makes the printer check feature useless? Is our collective time, mental energy, and emotional frustration not important to Prusa?

I don't see how any decision-makers at Prusa could deem this situation acceptable for us long-time users who have promoted and supported Prusa for so many years. I feel abandoned - just when it feels the MMU is finally being perfected!

As my two Prusa printers age (fairly gracefully), I'm thinking of adding a newer printer, and these kinds of experiences, both good and bad, very much affect my purchasing decisions. These experiences also guide how I recommend printer and printer manufacturers to those who seek my guidance. Think about it: Anyone brave enough to get an MMU2S early-on is probably enough of an enthusiast for others to seek guidance from. Our influence has directly affected Prusa's bottom-line and this enthusiasm is a major factor in Prusa's overall success over the years. And now, with some very serious competition on the market, I think it would be foolish for Prusa to cause hardcore enthusiasts to feel abandoned.

Printer checking worked just fine until 3.14.0, so this doesn't feel like something that cannot be fixed.

How about this proposed solution: A simple config item in the MK3S firmware that allows the user to select which type MMU they have?
Maybe where we enable MMU, instead of MMU = ON/OFF, in the menus, how about MMU = MMU3/MMU2S/MMU2/OFF?
That way it's all in one place and would require relatively minimal coding, and everyone is happy!

Again, I cannot thank you and the team enough for all the hard work getting us to this point. It's certainly better than having to constantly babysit my MMU2S as I did prior to 3.0.0.
I hope my appeal for a fix here does not diminish that gratitude.
Please consider my proposal above. I think it's a decent solution.
Thank you.

[github-actions]

Thank you for your contribution to our project. This issue has not received any updates for 60 days and may be considered "stale." If this issue is still important to you, please add an update within the next 7 days to keep it open. Administrators can manually reopen the issue if necessary.

[github-actions]

This issue has been closed due to lack of recent activity. Please consider opening a new one if needed.