Error: T command was suppressed and not sent to printer

Get Help
1

What is the problem?

Getting "Suppressed command" error when printing a multi-color model on the Prusa MK3s with MMU2s. Printer is not able to do a filament change and either pauses or continues printing without extruding filament.

Command_Suppressed_Error

Model prints fine until about layer 35 (5.30 mm) and then throws error. Color changes occurred successfully up until this layer. (Gcode located here: https://drive.google.com/file/d/1qEYHAGs3maHncX-iyIVte1f5NO9qqsY8/view?usp=sharing)

Contrary to what the error message states it appears my printer profile is set up correctly for the MMU2s:

Printer_Profile

What did you already try to solve it?

Re-sliced the model and rebooted Octoprint.

Have you tried running in safe mode and if so did it solve the issue?

No

Complete Logs

Octoprint.log attached.
octoprint.log (1.1 MB)

Additional information about your setup

Octoprint version: 1.5.1
OctoPi version: 0.17.0
Python version: 3.7.3

Printer: Prusa MK3s + MMU2s
Printer firmware: 3.9.1-3518
MMU2s firmware: 1.0.6-372
Slicer: PrusaSlicer v2.2.0 + win64

Browser: Microsoft Edge
Operating System: Windows 10 Pro

2 Likes
2

Did you configure multiple extruders in your printer profile?

2 Likes
3

Thanks for your response @PrintedWeezl. The printer profile is set up correctly for the MK3s + MMU2s. There are 5 "tools" with one shared nozzle. Even though the profile appears correct I am still getting the error. I have updated my original message to show the profile. Thanks again!!

4

I've been having this problem off-and-on with my correctly configured MK3S+MMU2S for several months. If I reboot the printer and restart Octoprint, Octoprint will detect 5 tools and print correctly, once. On subsequent prints, Octoprint will detect only a single tool, and skip the T messages.

Since upgrading to Octoprint 1.5.1 I'm seeing the new message, but the overall problem hasn't changed.

5

Since the message is suggesting there is some auto-detection going on: 'or was reported invalid by the firmware', maybe it gets a bad response at some point? serial.log of when the problem occurs would be useful (remember to enable it first!)

6

Well, I've got logging set to DEBUG in Octoprint, and I'm not seeing any log messages for the 'T' suppression.

7

Settings > Serial > enable serial.log, as the link says. It creates a separate file, and is completely different to the levels on the 'Logging' tab.

8

This is the serial.log file for a failed MMU2 print. Before the start of the print, I reset the printer. The GCode refers to T1 and T3, but during the print, it only printed using T1 (not T0). Before I reset the printer, the last tool used was T3 (not T1). I ended the print early when I noticed that it had missed a tool change on layer 1.

serial-failed-mk3s-mmu2s.log (320.3 KB)

9

Right now my workaround is that before any print, I need to have Octoprint disconnect and reconnect the printer. That forces the printer to restart. Then I manually do Load Filament / Load All from the printer controls. Once those two steps are complete, I can print one G-Code file. Then I repeat these steps for the next file.

This wasn't a problem in the past; I've been using Octoprint with this printer for more than 2 years; its only been the last couple of months where this has been a problem.

10

So, I noticed this at the start of your serial.log:

2020-12-06 18:55:26,767 - Recv: start
2020-12-06 18:55:26,769 - Printer sent 'start' while already operational. External reset? Resetting line numbers to be on the safe side

That means it reset while it was already connected, which I find a bit weird on its own.

Still, I found this:

2020-12-06 19:01:14,284 - Send: N281 M104 S230.0 T3*54
2020-12-06 19:01:14,285 - Recv: ok T:230.3 /230.0 B:85.0 /85.0 T0:230.3 /230.0 @:27 B@:67 P:30.2 A:39.5
2020-12-06 19:01:14,293 - Send: M109 S230
2020-12-06 19:01:14,300 - Send: N282 G28 W*108
2020-12-06 19:01:14,315 - Recv: echo:M104 Invalid extruder 3
2020-12-06 19:01:14,317 - Warn: T3 reported as invalid, reverting to T1
2020-12-06 19:01:14,325 - Recv: ok

Your GCODE tries to set a temperature for tool 3, your printer tells OctoPrint "I don't know that tool", so OctoPrint blacklists it.

I don't get why the GCODE here contains a T3 parameter on the temperature set command to begin with, since you have a shared nozzle that doesn't really make sense at all since you only have one heater.

This should be a plain M104 S230.0 instead. Or the firmware needs to learn to ignore tool parameters on the temperature requests. In any case, based on this log OctoPrint is doing everything like it should - the printer told OctoPrint it doesn't know a tool number 3 (though it did that in response to a temperature set command, not a tool selection command, but as pointed out, it should either not even be told to do that in the first place, OR the firmware must ignore these tool parameters for this to work), so OctoPrint no longer tries to tell the printer to use it as it expects to be told "no" again.

The question now is, does this T parameter come from the GCODE file you are printing? Or does it come from somewhere else?

11

This appears on a MMU2 when it does not find a filament on the "tool".
So when the gcode tries to print with T3, and there is no filament, the firmware redirects to T1.

12

Not the firmware, OctoPrint, that Warn line is stuff coming from OctoPrint. If a tool is reported as invalid by the firmware, OctoPrint will (attempt to) revert back to the previously selected tool, in this case T1.

1 Like
13

I see, I thought it was the firmware...
So, clever done in case of filament runout :+1:

14

Thank you all for your responses, but I think I'm confused. :frowning: So for some reason the printer could not sense filament in the T3 tool (firmware?) so it was redirected back to the previous tool (Octoprint?). So this error message is "normal" and expected under these conditions? And the problem lies with the printer?

15

I've noticed the same issue with my Ender 3 Pro with dual color since I updated to 1.5
Didn't have issue with previous version and didn't make any changes between update

16

I too was slightly confused, but I think I understand and will try and put it differently:

  • OctoPrint gets a response from the printer that T3 is invalid:
  • So it blacklists it (sensible?) and doesn't use it again, generating the error message when it goes to use it again, and instead uses T1.

I'm not too sure about the filament detection thing, not having one. I think the bottom of the issue is that this is an unexpected response from the firmware, handled correctly by OctoPrint - if someone told you not to do something, you don't do it again (well, maybe :wink:).

1 Like
17

As above, you need to enable serial.log, reproduce the issue and upload the log.

You more than likely did have the issue prior to the update, only difference is now there is a bright red popup. OctoPrint previously handled this silently.

1 Like
18

Just for the record, since I just remembered it due to a question on a bug report:

image
image999×848 48.4 KB

You can also disable OctoPrint's sanity checking of tool commands via Settings > Serial Connection > Behaviour > Sanity Checking.

2 Likes