Prusa MMU T? Not Working Via OctoPrint

Get Help
21

When the T9 is processed the printer pauses, could it be related to that? By the way: your beginning code is not correct for the new firmware, you should have a T9 where I see still a T?. The Slic3r printer setting tab must by updated wrt. that Gcode when the job is started. I also found that I had to increase my purge strip, so I made two instead of one purges.

Mine looks like this:

M109 S[first_layer_temperature] ; wait for extruder temp
G28 W ; home all without mesh bed level
G80 ; mesh bed leveling

G21 ; set units to millimeters

;go outside print area
G1 Y-3.0 F1000.0
G1 Z0.4 F1000.0
; select extruder
T9
; purge line
G1 X55.0 E8.0 F2000.0
G1 Z0.3 F1000.0
G92 E0.0
G1 X240.0 E25.0 F2200.0
G1 Y-2.0 F1000.0
G1 X55.0 E25 F1400.0

;RR Do it a second time...
G1 X55.0 E0.0 F2000.0
G1 Z0.45 F1000.0
G92 E0.0
G1 X240.0 E25.0 F2200.0
G1 Y-2.0 F1000.0
G1 X55.0 E25 F1400.0
;RR End second time

G1 Z0.20 F1000.0
G1 X5.0 E4.0 F1000.0

M221 S{if layer_height<0.075}100{else}95{endif}
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
G92 E0.0

22

And... in between compiling firmwares I made this: https://www.thingiverse.com/thing:3172330

1 Like
23

I really wish vendors would stop inventing their own codes. T? or TX don't make any sense from a GCODE perspective (in fact, even T<n> doesn't per se, but that's a different rant). If they want to have some code that triggers something on the printer's side on tool change, they either have to overload T<x> on their end, OR add an additional M code that is supposed to go before or after a T<n> and does their stuff. T9 is also wrong - it tells the printer to switch to a non existing extruder 9 and abusing it for some other arcane meaning is not a good idea, especially since I'm fairly sure I even have some code in there that filters out T commands that switch to an extruder that is known to not exist to prevent errors caused by incorrectly sliced files.

That T? doesn't get sent when streamed from a GCODE file but works just fine when encountered on the terminal sounds like a bug and needs some further analysis. Would be great if someone could open a ticket (please make sure to include logs and a file with which to test), I'd love to get this fixed ASAP.

What is T? supposed to do btw? I tried to figure it out from the discussion above but might have missed it.

24

T? gives the choice to select the filament/extruder from the printer panel (here)

BTW: I never had issues with the MMU V1 and OctoPrint in single and multi mode.
On the first glance, I do not see a difference of the MMU 2 gcodes to those of the MMU 1
I still assume that a plugin crunches up with the T? command.

25

What are they using it (T9) for?

26

I understood that T9 instead of T? was proposed to them by @Ruedli as a work around.

27

Let's see if I can reply again. This post limit on new users needs some work. I can understand the limit to avoid spambots, but have it limit the number of threads that can be replied to or new threads created. Limiting it to just a set number of posts can cause issues and this is an example. I had more information to post, but couldn't and there is no DM feature that I could find. So Ruedli and I were abruptly cut off from the conversation. Luckily, we were able to continue the conversation on another platform.

With that being said, because of this (Prusa) issue and some other issues with the MMU, I have decided to remove it for now until Prusa takes care of the issue. As Ruedli mentioned earlier, Prusa has said that the T? was not the correct way of doing this and are planning on implementing it the correct way with a M code (at least I am hoping they will). So I don't see that the OctoPrint folks should worry too much about dealing with this for now. Because of that, I'm going to mark this as solved.

28

Sorry for the double post, saw this too late:

Yeah, that definitely should be a custom M code then, not a completely new code format :confused:

1 Like
29

As a new forum user I had to wait some hours before my reply was allowed, so here comes the text I typed in earlier....

Indeed, there is a difference in underlying activity for T and T?. This is what causes the confusion, as I pointed out in Prusa's forum.

T triggers a tool change to extruder n+1
T? triggers interaction with a user on the printer's LCD panel with menu selection buttons -and- a subsequent tool change to the selected tool.

Because they are so different, it leads to undesired side effects. E.g. other users complained that it made no sense to wait for the menu interaction till the moment that the printer was heated up (which makes sense when you load filament).

Personally I would prefer one GCODE for triggering the interaction, the printer should store the result and then activate a tool change to this extruder with another GCODE command.

I'd leave it to the supplier whether the gcode T is applicable/fits anywhere, but to the letter T only switches to a defined tool that is known from the perspective of the GCODE, which is not even the case when you switch to a tool that is selected before through some other means (menu interaction in this case). Currently only the implementation of T0, T1, T2, T3, and T4 in the Prusa MK3/MMU2 seems compliant to that underlying principle of changing tools..

Reality is however unfortunately that Gcode streamers need to deal what every supplier designs in this area, as there is no standard for Gcodes that is maintained and enforced over all suppliers.

On the positive side, Prusa mentioned that they are reconsidering the use of T? and T and maybe will introduce other M codes, I can only hope they consider wisely and compliant to the syntactical definition of codes...

Further I think it is great hat Prusa allows the community to analyse and contribute at depth, by providing their firmware as open source and engaging in a discussion for that matter. Rethinking the design before implementation is a huge step further I think and would introduce all sort of other complications.

30

Indeed, I was "just" interested in getting Octoprint to work with my printer, and as the conversation went not in the direction I thought was correct (referring to contact they had with you and the sole information hat you had recommended that Prusa write an Octoprint plugin for their standard MMU2 to work), I decided to step in and demonstrated with a private firmware patch an alternative in the line of thinking: towards Prusa cleaning up the gcode definition they imposed.

For that I introduced a quick patch using "T9" instead of T?, which demonstrated a solution that would just require action on the firmware side.

T9 is in my opinion not the best long term solution, for many reasons. I was happy the Prusa indicated of rethinking T?, in the favour of new M gcodes, but lateron I got the impression it was to then still a matter of reviewing alternative TX and T9, which is a pity, but I cannot help it.

To me patching firmware of my printer to act on T9, allowed me to enjoy all the features of my new printer upgrade, the discussion on Gcode was not my primarly objective, but prooved indeed much more interesting.

So to summarize my findings:

On a regular unpatched latest firmware MK3/MMU2:

T? works when streaming gcode from the SD card.
T? works when issuing it from the octoprint terminal
T? does not work when streamed as part of a Gcode file from octoprint
T0,T1, T2, T3, T4 work for all this instances.

On my printer that I patched to both process T? and T9 as an alternative:
All the above cases work, provided you use T9 and not T?.

Unrelated to that, I am investigating why another octoprint user (Elroc) cannot see his 2D progress for a gcode T7 file, whereas I can. The positive test results summarized for me with respect to printing also applied to him.

In this context: which logfile for which scenario(s) with associated Gcode file would you like me to prepare?

cheers Ruud

31

I think I found the setting in question and increased it a lot.

The problem is that this simply doesn't scale. I can't put in special handling for every single printer vendor/custom firmware build out there. I already have to accommodate several mainline firmware forks and that is already making any work on the communication layer a maintenance nightmare.

We don't have a proper spec (as in, a static documented with well defined requests and responses - and I tried to fix that in the past but ran against tremendous resistance from the community...), but there IS a page about 3d printing GCODE in the reprap wiki, and if firmware vendors would at the very least adhere to what's on there they would severely reduce the horrible overhead that working around vendor peculiarities forces on anyone who tries to implement a gcode sender.

Keeping interaction with the thousands of firmware forks out there is really the worst part of working on this piece of software, and I'm getting to a point where I simply have to put my foot down (and refer outliers to the plugin system) or simply give up on this altogether as it would become completely unmanageable. I don't know about anyone else here, but personally I prefer the first one of these two options.

2 Likes
32

couldn't agree more! Really appreciate this effort you put in, but unfortunately it is like emptying the sea with a bucket...

1 Like
33

Appreciating effort without commiting and Patreonism is a bit fake, so I fixed that :wink:

2 Likes
34

@tedder42:

T9 was not introduced by Prusa, but in a patch done by me to the firmware of my private printer in an attempt to make it working as I wanted it to work. I am aware this is totally wrong for many reasons, that is what the Gcode discussion is about. Do not let "my T9" distract you.

35

@ElmoC

Do not know if you received my offer on the alternate channel to test with Gcode that does not work for you (displaying 2D print progress), on my octoprint installation, to see how it behaves there..

I was also thinking along the lines that perhaps in your octoprint setup the "colour" of T9 was transparent, but the absence of buttons to move to the layers in your case make that less probably.

I will wait for further info

36

Neither had I in my MMU V1, but then in single mode I never saw the prompt pop up and it always extruded from extruder 1 if I remember well. If I wanted another extruder I selected it with T0, T1, T2 or T3 and that worked, like it also works for the MMU V2.

The problem became more apparent as I found out that on my MMU V2 in single mode, on my Octoprint T? resulted in picking the "next extruder", which puzzled me and became problematic, as it was loading my PVA.

Al this can be the result of Prusa now including in their startup code this T?, which I am not sure whether they had that for the MMU v1. For sure the behaviour of the MMU v1 appeared different to me.

37

Hello @Ruedli!

As I still wait for my MMU V2, I only can make assumptions but I think when I finally have it, I can dig into this matter.
For T? works from the terminal and not from file, there must be something, that scrambles the gcode after uploading. Have you compared the code you upload and that one that was uploaded? Maybe that brings you closer to the fault. I still have the bad feeling a plugin is the reason...

38

I did see it but forgot to reply because of other issues. I can send you one tonight if you want. I didn't know about a tool color in OctoPrint but will check for that.

39

From Ruud Rademaker,

Excellent, I am out tonight, but will look into it when I m back, PM me at first.lastname@gmail.com

cheers Ruud

40

T? works on mmu 1.0. I've been using it for over a year now. I wonder what exactly has changed. I'm getting the MMU2.0 soon (week or two) and will be able to run some tests then. I've received reports of this issue in my Octolapse repo, so I will redirect users to this forum for discussion.

Also, WHAT ARE THESE MFGS THINKING! Why oh why can't they come up with a standard and just stick with it.. grrr... /EndRant