Prusa MMU T? Not Working Via OctoPrint

ElmoC · October 19, 2018, 10:12pm

Today I tried printing from OctoPrint to my Prusa i3 Mk3 with MMU2 in Single mode. Things started off fine until it got to the T? command Slic3r PE inserts to select which filament to use. At this point, the print stopped and never asked about the filament. When printed from the SD card, the T? doesn't cause any problems.

Is this something that is known and being addressed? Or do I need to make some changes to the Slic3r settings when printing with OctoPrint?

I saw another message about a possibility a plugin may be interfering, but there was never any follow-up as to which one.

Running OctoPrint 1.3.9 on OctoPi 0.15.1

Ewald_Ikemann · October 20, 2018, 7:11am

Hi @ElmoC

Have you tried the save mode with OctoPrint?
Also the log files could help a lot.

Ruedli · October 23, 2018, 12:47pm

Yes, I got the same problem and fixed it. The problem was related to T? in a file not properly streamed to the MK3. When you send the T? GCODE from the terminal tab of octoprint, it does work. In my case T? when streamed from the GCODE file tried to load filament into the next extruder.

As an immediate fix I updated in Slic3r in the printer tab, for the GCODE-custom code used when starting a print the T? into T0 (Use T1 for extruder 2, T2 for extruder 3, T3 for extruder 4 and T4 for extruder 5). With T0 it will always use the first extruder for that generated GCODE. On the downside: you can now not select the extruder to use after calibration, before the job starts printing.

In dialog with Prusa, they suggested that Gina had mentioned that Prusa should consider writing a Octoprint plugin to get the T? to work. This did not seem an optimal solution, because then people that wanted to use octoprint with the MK3/MMU in single mode, should not forget to install a plugin in order to print, how bad for a single GCODE... It could be related to a plugin interfering that messes up with the T?. The "new" prusa plugin should probably parse the gcode file for T? and then substitute it into a configured extruder in octoprint. So instead of a dialog, you have a configuration screen in octoprint.

Instead of waiting for that to happen, I dived into the MK3 firmware, made a fix and now my MK3 MMU2 supports T9 for bringing up the dialog, as originally the T? did. I can confirm that "T9" works with Octoprint as well now! A dialog popsup at the printer Three lines had to be changed in Marlin_main.ccp

Prusa will talk to their firmware guys for this and I will further test with an upwards compatible change.

Let me know if you are feel like fixing this yourself and compile firmware, it was easier then I thought, I did it over my lunch break, set it up from scratch.

ElmoC · October 23, 2018, 1:07pm

Thanks for the information. It was very helpful to know that it wasn't just me. I am a bit surprised this wasn't discovered earlier by Prusa given the have the internal OctoPrint board support.

I would be interested in making these changes. Might be good to make a post on how to do it and have Prusa pin it for others to see.

Ruedli · October 23, 2018, 1:49pm

Indeed, that was something I commented to Prusa as well, also for me it is good to know it wasn'r just me.

As I was of the opinion that the Slic3r should not send out code that does not work, I filed it a an slicer issue first. Later it turned out to be firmware, still, the temp solution involves the slicer. You find the discussion here:

You can also see the code lines to change in that discussion.

ElmoC · October 23, 2018, 2:15pm

Just read through the thread. Looks like you did a lot of research into this problem. Still not sure of a couple issues.

When sending T? from OctoPrint's terminal window, did that work as expected? It sounds like it did, but want to be sure.

If it works from the terminal window, what is actually being sent frown OctoPrint when streaming? It sounds like the real issue is in OctoPrint changing gcode when streaming.

Ruedli · October 23, 2018, 4:02pm

Not so much research, I was typing the answer yesterday late and then I thought, let me check the firmware what it actually does. By searching for the string on the display over all the files, I found how it was supposed to be called, and then I found the location and the T? logic was pretty obvious and isolated. Next was trying it out, which went very quickly as well, as I had an Arduino installation, but sofar I never compiled for the Rambo board. That was literally just one download away.

After I had confirmed that it actually works as I suspected, it was easier for Prusa to follow it up.

It definitely looks like something that has its root cause in Octoprint, but can easily be worked around in the firmware by Prusa.

As from your question, T? from the terminal does work in the standard firmware, but will not be streamed from a file as we found out.,

In my firmware updated for supporting T9, T9 works both from terminal and from the streamed file.

I now tested a firmware supporting T? and TX: both work from the terminal. but neither of them from the streamed Octoprint. So Doing TX instead of T? is not a good idea.

So, I will propose Prusa to do a T9 / T? patch, it is only 29 bytes more, compared to just supporting T9 only, had they structured the logic a bit, it could easily be even less, I choose "just to change the lines", and not optimze for code efficiency.

Finally, it would be worth knowing what in Octoprint is stopping both TX and T? from being streamed from file into the printer, but there the Prusa guys can't help. Any Octoprint (plugin) expert around for that question?

ElmoC · October 23, 2018, 4:19pm

I'm guessing the T? and TX violate gcode syntax. I think the letter must be followed by a numical value. When sending from the terminal, OctoPrint sends as is. When streaming, OctoPrint might be parsing the data stream and has issues on incorrect syntax like this. So could really be problems on both sides if T? violates the syntax.

Would you be willing to share your hex file with the changes?

Ruedli · October 23, 2018, 5:26pm

Yes, I can, but I need to make a disclaimer: Allthough I am an experienced programmer, It is the first time I built an Rambo image. The only proof that it worked, is that I successfully did 4 prints with it and it behaves as I coded it to be in the area where I made the changes. Also the size is comparable to the previous 3.4.1 firmware, but smaller then the 3.4.2 file..

I left details of the implementation on the Prusa forum.

Further: Prusa reacted and they also felt the T? was a bad idea and are considering the integrate something as a new M gcode. This will probably come in some future release.

Having said that, here is my hex file.
prusa3d_fw_MK3_3_4_2_patchT9.zip (208.4 KB)

It now supports both T? and T9. For it to work, you should unzip it and flash the MK3 with the hex file and update the customizable code in the printer section of Slic3r to use T9, where it now says T?.

Let me know if this worked.

Cheers Ruud

ElmoC · October 23, 2018, 5:40pm

Thanks. I am an experienced Software Engineer so know the problems that can be associated with it. Just have so many things on my plate, I wasn't looking forward to having to try and compile this.

Will give it a try tonight after work.

Ruedli · October 23, 2018, 5:47pm

For your comfort, I could flash three times with different implementations, so getting the original firmware in should not be too much of a problem and... I also used the firmware updater plugin of Octoprint two times, note that that only works if you are not using a raspberry connected through the header. My raspberry pi 3B is connected through the USB. I prefer the performance of that one so much over the zero.

After work? In the US? I live in Switzerland (while being Dutch)

ElmoC · October 23, 2018, 6:01pm

Not sure what you are saying with flashing multiple times. My pi is connected via USB so can use the firmware flasher plugin.

I am in the US and get off work in 2.5 hours {start around 5:30am so I can get home early)

Ruedli · October 23, 2018, 6:24pm

On the multiple flashing, just wanted to point out that my firmware experiment did not lock me out for flashing (other) new firmware. That was something that worried me, like a forgotten boot loader and then you could only flash using the on board ISP.

No worries therefore

ElmoC · October 23, 2018, 9:16pm

Was able to flash that firmware and do a print. Yea!!! But now, my GCode Viewer isn't showing the model. But I can at least put the sneaker net away for awhile now.

Ruedli · October 23, 2018, 9:23pm

Well, not over here, so it must be something unrelated...good luck away from the sneaker net (whatever that means ?)

ElmoC · October 23, 2018, 9:25pm

Seems to be the T9 causing the issue. When I change the T9 back to T?, it shows in the GCode Viewer fine. At least for this file. Will have to try another one and see what happens.

ElmoC · October 23, 2018, 9:28pm

Using T9...

ElmoC · October 23, 2018, 9:29pm

Using T?

ElmoC · October 23, 2018, 9:30pm

My starting GCode...

M107
M115 U3.4.0 ; tell printer latest fw version
M83 ; extruder relative mode
M104 S[first_layer_temperature] ; set extruder temp
M140 S[first_layer_bed_temperature] ; set bed temp
M190 S[first_layer_bed_temperature] ; wait for bed temp
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
T?
; 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
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

Ruedli · October 23, 2018, 9:35pm

great, is it perhaps showing a first (empty) layer? I noticed your next layer button is not available either... Strange...maybe it improves during the print? Do you have a plugin installed that processes the layers, for displaying the layer number and which analyses the gcode? I had problems with that one and disabled it a while ago.