I hear you. Trust me. I hear you. 
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.
NEW important information:
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.
2 Likes
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)
I have tried this, and it loads T0 then executes the T? with a filament choice menu.
Is this the same behavior you have as well ?
Thanks for trying this.
The behavior you get is partly what I am seeing.
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.
1 Like
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.
1 Like
Good catch. I saw it on Github but it didn't have release notes.
Relevant:
We have also fixed "T?" G-code function. There was a bug which caused that it didn't work for USB printing (for example with Octoprint).
1 Like
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.
1 Like
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.
BTW. Happy new year to all =o]
Hi @Szafran!
What plugins do you have with your OctoPrint installation?
Do you also have problems when staring OctoPrint in save mode?
Hi @Ewald_Ikemann I've done a fast check and running OP in safe mode seems to fix it.
As for the plugins that I run, here is a list:
Action Command Prompt Support
Active Filters Extended (0.0.2)
Announcement Plugin
Anonymous Usage Tracking
Application Keys Plugin
Autoscroll (0.0.2)
Backup & Restore
Bed Visualizer (0.1.7)
Core Wizard
Cost Estimation (2.1.2)
Custom Control Editor (0.2.1)
Discovery
Display ETA (1.0.2)
DisplayZ (0.1.0)
Exclude Region (0.1.3)
Filament Manager (0.5.3)
FloatingNavbar (0.3.0)
Fullscreen Plugin (0.0.4)
GCODE System Commands (0.1.1)
HeaterTimeout (0.0.1)
LayerDisplay (0.4.1)
Logging
MultiCam (0.2.6)
Navbar Temperature Plugin (0.11)
Octolapse (0.3.4)
Plugin Manager
Print History Plugin (1.2)
Printer Safety Check
Printer Stats (1.0.0)
PrintTimeGenius Plugin (1.3)
Software Update
System Command Editor (0.3.2)
Tab Order (0.5.0)
Themeify (1.2.0)
That's the list of the plugins that I have currently enabled. Any idea which one is to blame for my problems ?
Hi @Szafran,
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)
Comparing my list to Ewald's list, here are the ones I have that work that they had marked as unknown...
HeaterTimeout (0.0.1)
LayerDisplay (0.4.1)
Octolapse (0.3.4)
1 Like
@Ewald_Ikemann & @ElmoC thank you guys very much for that list.
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.
1 Like
@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).
1 Like
OctoLapse has an option to cancel a print if it can't initialize a camera feed. I believe it can be disabled.