Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[1.3.12] Reports of MMU2 restarting on filament select, caused by incorrect configuration of the printer profile #3314

Closed
foosel opened this issue Oct 23, 2019 · 12 comments

Comments

@foosel
Copy link
Owner

@foosel foosel commented Oct 23, 2019

Problem

There have been some reports on the forum that MK3s with the MMU2s attached are restarting under OctoPrint 1.3.12.

I'm eagerly awaiting logs (especially serial.logs showing the issue), reproduction steps (the more info on the specific operation modes, firmware versions and hardware revisions this happens in the better), information whether it happens in safe mode or not - in short, fully filled out issue templates. But also information on whether it maybe works for some people with the MMU (in which case it will be interesting to figure out the differences to the setups it doesn't work in, so again, the more info the better).

Solution

As of yet undetermined, analysis impossible without data.

The reason appears to be misconfigured printer profile that do not state the correct number of available extruders.

For MMU2, five extruders and a shared nozzle should be configured.

image

Failure to properly configure the printer profile will cause a range of issues due to OctoPrint suppressing the tool change commands to (to it) unknown tools which appear to range from wrong filament selection to outright crashes of the MMU and printer. The behaviour displayed here is completely outside of the control of OctoPrint. Fixing the configuration solves the issue.

@rusher2000

This comment has been minimized.

Copy link

@rusher2000 rusher2000 commented Oct 23, 2019

serial (2).log

Please see attached serial log. I'm new to this, so hope i did it correctly.

I have a MMU2. Installed the update this morning before reading the warning that i might should wait.

The printer goes through the setup-heating nozzle and bed, self leveling and this pauses. this is when the filament would normally load. It sits for a while then begins the setup routine all over again. It has looped a few times.

Until there is a fix, can you post a link to install the previous version so i can get back to work?

@foosel

This comment has been minimized.

Copy link
Owner Author

@foosel foosel commented Oct 23, 2019

2019-10-23 12:23:53,595 - Not queuing T2, that tool doesn't exist according to the printer profile or was reported as invalid by the firmware

Please make sure your printer profile actually defines all your available extruders. This looks like it doesn't and that could very well be the source of your issue (which doesn't appear to involve the full resets that some people reported).

image

Until there is a fix, can you post a link to install the previous version so i can get back to work?

You can find that link under every single release announcement I put out, but here it is again:

https://community.octoprint.org/t/how-can-i-revert-to-an-older-version-of-the-octoprint-installation-on-my-octopi-image/205

@rusher2000

This comment has been minimized.

Copy link

@rusher2000 rusher2000 commented Oct 23, 2019

I made the setting changes to my printer profile (named Prusa3D) you showed above. I did not have to do this for the previous versions and had been printing without issues.

The bad news is ... I deleted the previous serial.log file thinking it would create a new one, but that does not seem to be the case. Sorry about that. If there is some way to create that file again, id be happy to try that so you can see the file. (again I'm new to this posting stuff so be patient).

The good news is ... This time the printer went through its setup procedure and then the MMU2 started working (this did not happen before). The filament loaded and now i'm printing. I think this fixed the problem. I am only printing with one color on this file and it seems to be working. THANKS!

@foosel

This comment has been minimized.

Copy link
Owner Author

@foosel foosel commented Oct 23, 2019

I did not have to do this for the previous versions and had been printing without issues.

Yeah, the code to perform this sanity check was in for a while (and was placed to prevent firmware crashes in case of undefined tools) but it was faulty and didn't trigger properly. It does now in 1.3.12 so a correctly configured printer profile is necessary.

Glad that seems to have at least solved your problem. Also interesting that you are now printing successfully, so it's not a general issue from the looks of it.

Can you tell me what precise printer and MMU models you have and with which firmware?

@rusher2000

This comment has been minimized.

Copy link

@rusher2000 rusher2000 commented Oct 23, 2019

Prusa MK3s MMU2s
Firmware file name: prusa3d_fw_3_8_0_MK3S_1_0_6_MMU2S
MK3S: 3.8.0-2684
MMU2: 1.0.5-297

I'll note that the zip file shows a newer version for the MMU (1.0.6), but this info above was pulled from my printer's screen. I'm not sure if there is an separate routine to run to update the MMU using the Octopi or not.

@foosel

This comment has been minimized.

Copy link
Owner Author

@foosel foosel commented Oct 23, 2019

I'm not sure if there is an separate routine to run to update the MMU using the Octopi or not.

I fear I can't tell you either, I don't have access to one. But it will be interesting to see if there is maybe a pattern regarding people encountering the crashes and people not encountering those.

If there is some way to create that file again, id be happy to try that so you can see the file.

serial.log should always get written anew when you open a connection to the printer. So simply reconnecting should do it. Sounds like your issue is solved though, so right now I'd say no need for one.

@rusher2000

This comment has been minimized.

Copy link

@rusher2000 rusher2000 commented Oct 23, 2019

Thanks again for the help. I really like using this over WiFi instead of plugging in a SD Card.

@foosel

This comment has been minimized.

Copy link
Owner Author

@foosel foosel commented Oct 23, 2019

You are welcome. Let's just hope the weird resetting behaviour some people are seeing is equally easy to solve. Judging by the changes to the comm layer between 1.3.11 and 1.3.12 it cannot really be anything big...

@johnnyruz

This comment has been minimized.

Copy link

@johnnyruz johnnyruz commented Oct 23, 2019

@rusher2000 Glad you're up and running.

I'm not sure if there is an separate routine to run to update the MMU using the Octopi or not.

As far as updating the MMU, follow the Prusa guides on that. There is a dedicated USB port on the control board for the MMU you will need to connect to your computer and flash through PrusaSlicer with the Special MMU Firmware HEX file. To my knowledge there is no way to update the MMU firmware through OctoPrint and/or the USB connection on the RAMBO. The latest version is 1.0.6-372 and is working great with 1.3.12 with a properly configured printer profile. The profile seems to be the silver bullet for getting the MMU to work correctly with 1.3.12.

Thank you very much @foosel for the great support on this issue!

@foosel

This comment has been minimized.

Copy link
Owner Author

@foosel foosel commented Oct 24, 2019

So, to summarize the current findings:

  • The core reason for any kind of issues between OctoPrint 1.3.12 and the MMU2 is misconfiguring the printer profile with regards to the available extruders. It should be five extruders + shared nozzle for an MMU2 (and four + shared nozzle for an MMU).
  • For some people, this misconfiguration "only" causes the print to run with the wrong filament. For others, it causes a resend loop. For yet a different set of people, it causes MMU + printer resets. I have not been able to figure out a pattern here.
  • In all reported cases so far where the affected user came back to me after fixing their printer profile, it also fixed the observed issue, regardless of which of the three variants they were facing.

Long story short: the issue here is a misconfigured printer profile and possible a FW issue causing the resets due to that. I'm unclear on the reason for the resets, but that's rather something for the (FW?) authors of the MMU to figure out in any case.

I consider this solved at this point. It's not an OctoPrint bug but rather a misconfiguration plus possibly a FW bug, and fixing the printer profile to correctly reflect reality appears to be the solution.

@foosel foosel pinned this issue Oct 24, 2019
@foosel foosel changed the title [1.3.12] Reports of MMU2 restarting on filament select [1.3.12] Reports of MMU2 restarting on filament select, caused by incorrect configuration of the printer profile Oct 24, 2019
@foosel foosel closed this Oct 24, 2019
@JohnOCFII

This comment has been minimized.

Copy link

@JohnOCFII JohnOCFII commented Oct 24, 2019

You might consider rewording this comment:

This information is used for the graph and controls available in the "Temperature" tab, the GCODE viewer and when slicing from within OctoPrint. It does NOT influence already sliced files that you upload to OctoPrint!

Reading that, a user who never slices within OctoPrint might decide that changing the extruder configuration is not needed.

@foosel

This comment has been minimized.

Copy link
Owner Author

@foosel foosel commented Oct 25, 2019

@JohnOCFII Yep, I noticed this too, that's on the todo list, but too late for 1.3.12.

edit see c8d162c

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.