search

jukebox42 / Octoprint-PrusaMMU

An Octoprint plugin that adds MMU support.
GNU Affero General Public License v3.0
13 stars 2 forks source link

MMU2 Updated to latest firmware - No longer receiving valid Tool ID info #30

Closed skellied closed 10 months ago

skellied commented 10 months ago

Hello - After updating my MK3S and my MMU2, I can no longer select an MMU filament slot/tool. When selecting the filament slot in Octoprint, an error is returned: Suppressed Command: The command T2 was not sent to the printer: Not queuing T2, that tool doesn't exist according to the printer profile or was reported as invalid by the firmware. Make sure your printer profile is set up correctly.

If I wait a minute or so, the machine then starts beeping and I can manually enter the correct filament selection and it then prints like normal.

jukebox42 commented 10 months ago

Hey @skellied,

Haven't had a chance to test out the new firmware yet. Another user mentioned restarting Octoprint and their printer corrected the issue for them. Worth trying first if you haven't already. I should have some time this weekend to dig in and try the upgrade.

jukebox42 commented 10 months ago

Looks like the interface for the MMU2 3.0.0 is different. I've confirmed color selection still works but the navigation status data isn't working as expected. I'll work on a fix for that.

Kevman323 commented 10 months ago

I've spent a bunch of time looking into how the new 3.0.0 MMU firmware works, so I thought I'd share with you what I've figured out so far from the Prusa-Firmware repository.

As seen in the serial log, the MMU has a lot of simple communications that are hard to figure out. However, it also outputs simple things, like status messages, and errors in plain text. "Feeding to FINDA", "Disengaging Idler", "FSENSOR DIDNT TRIGG." "MMU MCU ERROR", etc. The status messages are listed in Firmware/mmu2_progress_converter.cpp, and the error messages are listed in Firmware/mmu2/errors_list.h

I assume these messages would be good for most important info/errors. Having a much more detailed MMU status in the header bar would be cool! However, there's no message for figuring out which filament is loaded. Of course you can take the T(X) value from the gcode going to the printer for multicolor prints, and you can see which option a user picked in the dialog box, but I'm not sure if there's a way to see which filament was picked using the LCD menu, without going into the more complicated communication messages.

Additionally, there's a bug I found while testing stuff out today. If the same message repeats, it doesn't get logged. This seems like a non-issue, but the problem is that both the status messages and error messages are counted separately. Here's an example, lets say that the filament gets stuck while loading. The error "FSENSOR DIDNT TRIGG." is printed in the logs, however, the automatic retry works, and the "OK" status message is printed, and the print continues. There are lots of other status messages in the meantime, "Engaging Idler", "Feeding to extruder", "Disengaging idler", etc., but these are all status messages, so they don't reset what the last ERROR message was. Now, another filament tip gets stuck. An error is thrown, but since it's the same as the last error, the error message doesn't get printed to the log. After 3 automatic retries, it gets stuck on the 4th attempt, and waits for user intervention, without ever printing that error to the log again. There's other messages, like "Heater cooldown pending", "and "Cooling Timeout started", that show that there's a problem, but they don't tell what the error is for. I'm going to post an issue about this on the Prusa firmware GitHub page, and hopefully they fix it.

In the meantime, you could use the Printer-MMU communications themselves. Once you figure it out, it's not to hard to understand. A simple command/response looks like this in Octoprint's serial logs:

echo:MMU2:>L0*73.
echo:MMU2:<L0 A*37.

Essentially, the printer sends a request message formatted like this:

>(MsgCode - The type of request)(uint8 - The value/address of the MsgCode)(uint16 - Optional value for write messages)*(CRC check)

And the response from the MMU is:

<(RequestMsg - The Code/Value pair it's responding to)(ParamCode - The response to the request)(uint16 - An optional extra value)*(CRC check)

So the above example is:

echo:MMU2:>L(Load)0(Filament 0)*73(CRC)
echo:MMU2:<L0(Load Filament 0) A(Accepted)*37(CRC).

Note that the log outputs all values in hex, except for the MsgCodes.

The printer Sends/gets these messages about once a second:

echo:MMU2:>Q0*ea.         >Query 0 - A general check to see what the MMU is up to
echo:MMU2:<L0 P5*bf.      <Load0 Processing 5 - In response to Q0, the MMU responds with the last command it worked on, Load0, and it's status. In this case, it's still working on loading the filament, and it's responding with message 5, which is "Feeding to extruder"
echo:MMU2:>f0*21.         >FilamentSensor 0 - Telling the MMU the Filament sensor status, in this case, 0. This seems to be only sent when needed.
echo:MMU2:<f0 A*c5.       <FilamentSensor0 Accepted
echo:MMU2:>R8*81.         >Read 8 - Read the value of register 8, which is the FINDA state
echo:MMU2:<R8 A0*8d.      <Read8 Accepted 0
echo:MMU2:>R1b*9e.        >Read 1b - Selector slot
echo:MMU2:<R1b A0*68.     <Read1b Accepted 0
echo:MMU2:>R1c*88.        >Read 1c - Idler Slot
echo:MMU2:<R1c A0*b7.     <Read1c Accepted 0
echo:MMU2:>R4*7b.         >Read 4 - This is the number of MMU errors. It seems to be set to 0x50 when the MMU resets/powers on
echo:MMU2:<R4 A52*40.     <Read4 Accepted 52
echo:MMU2:>R1a*f5.        >Read 1a - Pulley Position. Perhaps the position of the selector head?
echo:MMU2:<R1a A43*25.    <Read1a Accepted 43

And Lastly, an error response to a Q0 looks like this:

echo:MMU2:>Q0*ea.          >Query 0
echo:MMU2:<T0 E8087*f1.    >Tool0 Error 8087 - "Tool" is for loading the filament to nozzle. Error 8087 is "SELECTOR CANNOT HOME"

For a list of MsgCodes and ResponseCodes, see Firmware/mmu2_protocol.h.

The PXX response to the Q0 message are the general status messages that I linked near the top in the "mmu2_progress_converter.cpp" file. You have to map the message number of "progressTexts[] PROGMEM" to the actual message.

And unfortunately, the error messages are even harder to map. The codes you'll see in the log are in Firmware/mmu2/error_codes.h, but these errors are then converted in Firmware/mmu2_error_converter.cpp, and finally, that new value is mapped to a message, description, and other info in the "Firmware/mmu2/errors_list.h" file I posted near the top.

Phew, this ended up being a lot longer than I thought it would. I'm not confident in my ability to try and figure out GitHub and Octoprint plugins well enough to make a pull request, so hopefully this info will help save you from the digging I had to do to figure all this out!

Lastly, I'll post a long octoprint log that I made while testing this. You'll see the MMU MCU ERROR that unfortunately plagues my unit. I also purposefully cause a filament sensor loading error, FINDA sensor loading error, selector homing error, and do some basic stuff like cut a filament tip, just to see how the logs match up with the firmware info. I've marked important points in the log with "INFO: xxxxxx" to help see what is going on.

serial.log

Thanks for your work on this plugin. I love Octoprint, and as an MMU2S owner, this is fantastic to have!

jukebox42 commented 10 months ago

Amazing work, I really appreciate this detailed deep dive. I went down a similar rabbit hole this week trying to stop the bleeding and get an iteration out that at least restores the main nav to working order. I just pushed up my working branch here. The only interesting part is the stuff in __init__.py where I tried to remap the string messages from 3.0.0 to the states I already had defined. I haven't tested this yet, that's tonight's adventure.

For identifying what filament is being loaded/unloaded ect I currently don't rely on the MMU log data. I look for the T# in the gcode to define that and just keep it in memory with a previous and current variable. The previous MMU did not report that data. The only data I try to pull from the MMU is that state info. I think I can get a lot fancier with the new log data available, but I'll save that for the next release, I'm excited at the idea of showing the exact error, the previous firmware gave us nothing.

These are the states I think I've mapped out so far (but haven't tested):

However, you got much further than I did debugging the actual logs that fly past and what they mean, really appreciate that so thank you. I'll start digging through that data you have and the logs you've sent in my testing tonight so I can make it more accurate. Going to try and get a version out this weekend that restores it, then it'll be off to figuring out how I can improve things.

FWIW I'm getting a similar MCU panic, I'll see it firing from idling. Looking at their support logs it seems like they know they have that issue and plan to fix it in the next patch.

Kevman323 commented 10 months ago

Good works so far, that will likely restore the original functionality. All the MMU status info is there, it just depends on how much of it you want to use. You could even display Filament Sensor and FINDA status if you wanted to!

The messages are the good and easy way to look for errors, but it's unfortunate that that bug exists. I fear that, for example, the MMU will Print "OK", then you might have an MMU MCU ERROR, fix it, then the printer won't print "OK" again due to that being the last status message. It should be pretty rare, but it could happen. I did open an issue about it on their firmware page. https://github.com/prusa3d/Prusa-Firmware/issues/4346

And interesting to hear about a possible firmware fix for the MMU MCU ERROR. That error essentially means that the MMU's chips are not getting enough power, and since there's a known power flaw with the MMU mainboard, I figured the only fix is going to be the PD addon power board that the MMU3 upgrade ships with. Even Prusa email support that I just spent 3+ weeks talking to suspected I have faulty wires, and didn't mention anything about a firmware fix.

jukebox42 commented 10 months ago

Hey @skellied. I just released a new version that should repair the nav data. Appreciate the help! I'm going to resolve this thread. If you find any issues let me know. There's a lot more I can do with the data but I wanted to get a quick one out first.

schwabe commented 10 months ago

@jukebox42 the MMU Panic is often due to low voltage since the 5V rail is messed up. You can fix that with the new PD buddy board of the MMu3 upgrade kit or just attach a 5 (or better 5,2V) USB power supply to the MMU.