Yes, I do not recall issues either on the MMU 1.0. Yesterday I ran into another aspect of T? not working for MMU2. It appears that the FIRST T[n] command is not taken into account properly. In my case, a T0 resulted in a switch to channel 2 ( so 1 was loaded and after unloading it loaded the filament of channel 2, indicating 1>2 on the LCD)
It applied to single material MMU profile (where there is only one T-Gode) and multi material MMU profile, where it affected the first layer and subsequent tools for that layer and all tool changes layers after that were fine .
I resolved it as a work around by inserting a "dummy" T0 in the profile gcode "before the print starts"; before the actual T[n] command that was already in the profile. This resolved issues I had in both profiles _for my (patched) firmware.
It seems to me that this issue is rooted in the firmware of the MK3 interpreting T gcodes coming from the streamed input, so not related to Octoprint. When printing from SD cards I do not recall seeing this.
Note that I use patched / self compiled MK3 firmware, which however should have no impact to this behaviour specifically. Will try with the stock firmware lateron.
The issue was not tied to T?, but to the processing of the first T gcode when streamed.
when I found that it did not interpret correctly:
In a multicolor gcode file, the FIRST T command
in a single material MMU gcode ith the first (and only) command
I went back to the stock firmware and added an additional T0, before the actual T command (either T[initial_layer] or T?) in my profile under GCODE when print starts.
This worked as a workaround and I did not need a patched firmware to have proper processing of the (now second) T? command
Therefore the concentration of where the issue is should be in my opinion not on T? but on under which circumstances the first T command gets dysfunctional.
Hope this additional information is useful, it significantly impacts the hypotheses of the likely cause of the problem.
Have you tried OctoPrint save mode?
There are some plugins (like OctoPrint-gcodestatEstimator and OctoPrint-PrintTimeGenius) that analyse the gcode and may stumble about the T? or T command.
(BTW: I hope my MMU2 at last is shipped on 3rd of December)
The response to the first T0 is not predictable in my situation:
From SD card it always worked as intended
From Octoprint I have seen different behaviours for the first T0: Loading channel 1 (correct), but also switching to channel 2 (1>2 displayed, subsequent T0's load channel 1 without problem).
This non-predictable behavior was problematic. Adding a T0 before the actual T command needed was not so much of a burden, provided I at least loaded filament in channel 1 and channel 2.
The reason for posting the "update", is that at first I considered it was related to the printer not handling well the streamed T? command. T? is not what triggered the problem, it is the (sometimes) erroneous handling of the first T gcode, whether this is T?, T0, T1, T2, T3 or T4.
From Octoprint I have seen different behaviours for the first T0: Loading channel 1 (correct), but also switching to channel 2 (1>2 displayed, subsequent T0's load channel 1 without problem).
This is actually what I am experiencing now that I have printed more.
Thanks for confirming. In my opinion it indicates a problem in the Prusa firmware (3.4.2 (MMU V1.0.2)), because I did see the correct T code in the terminal together with a wrong response from the printer.
fyi. when I used a T1 as only GCODE command, i got filament loaded from position 3 (2>3 was displayed)
IMHO, Until it is resolved you're best off with the work around and use the extra T0 and filament loaded in both channel 1 and 2.
After further looking into it, I found it was not specifically related to T?, but to the fact the T? was the first (and only) load filament command in the GCODE stream, see the dialog on this issue further on and the work around that works for me.
I feel it is on the Prusa side in interpreting streamed GCODE and not caused by Octoprint. I have also posted this opinion to the Prusa firmware team.
New Rc firmware posted from Prusa.
Have not tried to flash yet, but just updating this thread.
It looks like there are changes/fixes to single filament mode, and T? codes
Improved printing in single material mode (new Tx, Tc codes and T? fixed)
UPDATE: Flashed firmware RC with updated start code (Slic3r not auto updated yet) and performing first print was a success, with new startup routine in single filament mode. Much more efficient procedure too. I Did not experience the same Z height issues as ElmoC below.
Got the new version loaded and changed my start g-code to use the Tc/Tx. So far, so good. It asked for the filament to used and loaded it to the start of the gears. Waiting for it to heat up so hopefully all will be well.
UPDATE: Print started just fine. Finished loading the filament and started the print. However, I needed to adjust the Z height so stopped the print and ran the first layer wizard. During the wizard, I bumped the bed during the calibration and it reported the failure, but did the Z calibration and started the 9 point calibration and then the first layer print.
I'm experiencing this now with my setup (newly connected MMU to my MK3 - I've assembled it some time ago, but haven't got the time to connect it).
MK3 FW: 3.5.1
MMU2 FW: 1.0.3
OP: 1.3.10
Slic3r PE: 1.41.2
I haven't tried any start g-code chenges to check if they would work.
I'll try them soon.
hard to say what plugin exactly. Sometimes plugings interfere to each other and cause problems.
I've compared your list with the plugins I have installed and marked all of those with a W that make no problems with me. Those with a ? need to be checked.
You may can start with Print Time Genius. You don't need it anyhow, because slic3er produces quite correct time estimations. You can use M73 ETA Override instead.
W Action Command Prompt Support
? Active Filters Extended (0.0.2)
W Announcement Plugin
W Anonymous Usage Tracking
W Application Keys Plugin
W Autoscroll (0.0.2)
W Backup & Restore
W Bed Visualizer (0.1.7)
W Core Wizard
? Cost Estimation (2.1.2)
W Custom Control Editor (0.2.1)
W Discovery
W Display ETA (1.0.2)
W DisplayZ (0.1.0)
W Exclude Region (0.1.3)
? Filament Manager (0.5.3)
W FloatingNavbar (0.3.0)
? Fullscreen Plugin (0.0.4)
? GCODE System Commands (0.1.1)
? HeaterTimeout (0.0.1)
? LayerDisplay (0.4.1)
W Logging
? MultiCam (0.2.6)
W Navbar Temperature Plugin (0.11)
? Octolapse (0.3.4)
W Plugin Manager
W Print History Plugin (1.2)
W Printer Safety Check
W Printer Stats (1.0.0)
? PrintTimeGenius Plugin (1.3)
W Software Update
? System Command Editor (0.3.2)
W Tab Order (0.5.0)
W Themeify (1.2.0)
So now I just have to test those plugins:
Active Filters Extended (0.0.2)
Cost Estimation (2.1.2)
Filament Manager (0.5.3)
Fullscreen Plugin (0.0.4)
GCODE System Commands (0.1.1)
MultiCam (0.2.6)
PrintTimeGenius Plugin (1.3)
System Command Editor (0.3.2)
And that's a lot less testing thanks to you.
Ok. So I'm off to with the tests. Will get back here to post my results.
BTW @Ewald_Ikemann thanks for the info about M73 ETA Override. Will give it a go.
@Ewald_Ikemann thanks for the tip on the M73... plugin, but Print Time Genious is just so much better and more integrated with OP.
As for my printing problems it turns out that the promatic plugin is in fact Octolapse (0.3.4). I have my printer now in a temp setup to test most of the things that I want to implement with it before designing a lot of stuff (eg. enclosure), and haven't got to reconnecting my cameras. And that was the problem.
With no cameras connected and Octolapse enabled = no printing. After connecting the cameras prints start without problems. I know it's weird, but that is what is happening on my config (I've tried a few times and every time without cameras there was a problem).