Wrong Filament being selected by Prusa MMU 2.0

Get Help
1

What is the problem?
When sending a MMU file via OctoPrint, the wrong filament channel is being selected.

What did you already try to solve it?
By sending via SD card - it works fine that way

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)

OctoPrint 1.3.9 running on OctoPi 0.15.1

Here are parts of the log file and GCode file.

Serial log...

2018-11-04 10:23:08,002 - Send: N52 M117 ETA 13 38 06 Day 04*20
2018-11-04 10:23:08,010 - Recv: ok
2018-11-04 10:23:08,022 - Send: N53 M403 E0 F0*17
2018-11-04 10:23:08,029 - Send: N54 M403 E1 F0*23
2018-11-04 10:23:08,033 - Recv: MMU <= 'F0 0'
2018-11-04 10:23:08,258 - Recv: ok
2018-11-04 10:23:08,269 - Send: N55 M403 E2 F0*21
2018-11-04 10:23:08,274 - Recv: MMU <= 'F1 0'
2018-11-04 10:23:08,390 - Recv: ok
2018-11-04 10:23:08,400 - Send: N56 M403 E3 F0*23
2018-11-04 10:23:08,401 - Recv: MMU <= 'F2 0'
2018-11-04 10:23:08,491 - Recv: ok
2018-11-04 10:23:08,503 - Send: N57 M403 E4 F0*17
2018-11-04 10:23:08,505 - Recv: MMU <= 'F3 0'
2018-11-04 10:23:08,594 - Recv: ok
2018-11-04 10:23:08,601 - Send: N58 G1 Y-3.0 F1000.0*21
2018-11-04 10:23:08,605 - Recv: MMU <= 'F4 0'
2018-11-04 10:23:08,697 - Recv: ok
2018-11-04 10:23:08,704 - Send: N59 G1 Z0.4 F1000.0*61
2018-11-04 10:23:08,711 - Recv: ok
2018-11-04 10:23:08,721 - Send: N60 T0*12
2018-11-04 10:23:08,728 - Recv: ok
2018-11-04 10:23:08,735 - Send: N61 G1 X55.0 E32.0 F1073.0*126
2018-11-04 10:23:10,921 - Recv: echo:busy: processing
2018-11-04 10:23:12,993 - Recv: echo:busy: processing
2018-11-04 10:23:15,091 - Recv: echo:busy: processing
2018-11-04 10:23:17,212 - Recv: echo:busy: processing
2018-11-04 10:23:19,305 - Recv: echo:busy: processing
2018-11-04 10:23:21,370 - Recv: echo:busy: processing
2018-11-04 10:23:23,467 - Recv: echo:busy: processing
2018-11-04 10:23:25,540 - Recv: echo:busy: processing
2018-11-04 10:23:25,977 - Changing monitoring state from "Printing" to "Cancelling"

And the corresponding gcode lines...

; Send the filament type to the MMU2.0 unit.
; E stands for extruder number, F stands for filament type (0: default; 1:flex; 2: PVA)
M403 E0 F0
M403 E1 F0
M403 E2 F0
M403 E3 F0
M403 E4 F0


;go outside print area
G1 Y-3.0 F1000.0
G1 Z0.4 F1000.0
; select extruder
T0
; initial load
G1 X55.0 E32.0 F1073.0

On the display, the filament shows changing from F1 to F2. Since it was already on F1 (T0), it should not need to change. The one thing that stands out to me is this...

2018-11-04 10:23:08,022 - Send: N53 M403 E0 F0*17
2018-11-04 10:23:08,029 - Send: N54 M403 E1 F0*23
2018-11-04 10:23:08,033 - Recv: MMU <= 'F0 0'
2018-11-04 10:23:08,258 - Recv: ok

There is no response to the first M403 command.

MK3_Doors_0.15mm_ABS_MK3MMU2.gcode (2.6 MB)
serial (1).log (25.4 KB)

2

As I understand, the (new) M403 gcode is for setting the MMU to the correct parameters for different filament types

; Send the filament type to the MMU2.0 unit.
; E stands for extruder number, F stands for filament type (0: default; 1:flex; 2: PVA)

so I do not expect any response.
The selection of the filament for print is done by the T0 command.

I think it's based on the same problem you mentioned with the other thread.

3

The other thread deals with a T? command that doesn't match the standard format for gcodes.

If you look at the 5 M403 commands, you will see the first one does not have a response, but the other 4 do. What is confusing to me is OctoPrint still sends the T0, but the MMU tries switching to F2 (T1). Almost like the non-response from the first M403 made the MMU think that channel wasn't there.

EDIT: Going back and looking again, there is a 5th response. But they are now one command off from each other.

4

The printer buffers two or three commands, so the receive prompt can be come out with a delay.