What are these (annoying) delays of 500ms good for? Normally an action should be triggered, when a button is pressed, or at least, when it was released.

When starting a print after cancelling/stopping the previous print.... the MMU will load the first filament, then the pulley motor does not respond to unload that color, or attempt to load the second. The X-carriage also slams into the X-idler when doing the initial purge line in the front of the buildplate, then goes on it's merry way. I have had this issue before countless prints, no matter what the object is.
Mk3 MMU2.0
FW 3.5.0, MMU1.0.1

somewhat similar to #90 without Octoprint

this is a link to the original issue in the printer firmware: prusa3d/Prusa-Firmware#1237

From the hardware standpoint of view, it should be possible to recover.
Could be easily implemented when MMU wasn't moving during power loss. If it was moving, it would be a bit harder to recover.

But since it's not time critical, what the MMU does, a comprehensive recover procedure should be working fine:
If filament is not in the bondtech gears at the extruder, there should not be any problem at all.

• home the idler drum only
• engage filament with idler drum
• Retract the filament until the FINDA is clear again
• park the filament on it's default position,
• home the selector too
• aks the printer what filament should be loaded
• ready for printing again

Most of my MMU interactions center around recovering from printer errors.

When you reset because of a lost home (most often), you typically end up in what I'll call the "default state". In that state, the middle button pre-loads (gets filament to the ball sensor and pulls it back a preset amount), and left and right move over to the next channel. (#58 is relevant here as you may skip most resets you see in actual product use)

It would be nice to have an interface similar to the .. other menu I don't know the name of (#33) the center button pre-loads and the right button hands off filament to the printer.

Since most of the time, in practice, I work on the printer I want a way to pick up where I left off, and most of the time the printer is waiting for filament to come to it, it would be great if the MMU could pick up as if that were the case.

I'm sorry I can't phrase it better, I've sat on this for two weeks because I can't put it succinctly. I really feel it would benefit your users, many of whom give up on a print because they are stuck once. My workaround has been to request a filament change, but at minimum that's a command buffer's number of empty lines and ruins a print.

Let me know if I can help explain it better or illustrate.

Can you please specify which bootloader to use on the Controller. It is missing from the documentation.

For fitting the MMU on top of a LACK enclosure, the provided orange PTFE is too short. After fitting a longer PTFE tube, I found that calibration limits exist in the firmware.

After changing: "eepromBowdenLenMaximum" (I added 4000 to the existing value) in permanent_storage.cpp

I could calibrate for my longer PTFE tube.

Can this setting indeed be increased for a next release?

In a single color print, my start gcode selects the filament at the beginning (Tx), before anything else (so i can make sure it loads correctly).

If i then cancel the print before it loads it into the extruder (Tc), which in my case is just before the purge line, then it does not eject the filament, and i can't also do it through the menu because the nozzle is still not hot enough and doesn't let me, so i have to open the MMU2 to do it manually.

Since the filament is still at the gears, the MMU2 should be able to eject it between the Tx and Tc commands.

When the printer is in this condition (All lights flashing) the selector is sometimes engaged making it impossible to pull out the material or unload the extruder. Rotate the selector to a disengaged state when booting and filament is detected OR allow the buttons to rotate the selector even if position is unknown.

Sometime it does sometime it doesn't...
Most of the time it goes to the left and force and then home wrongly.
Revert to official which home properly but somehow the loading was better with the beta, less grinding .

Is it possible to create a way to change the speed that the filament is fed and unloaded through the PTFE tube to extruder? I have a filament that grinds unless its fed through very slowly (cheap BVOH from push plastic) and was wondering if it was possible to switch speeds without flashing the firmware every time. It would be best if this was implemented in both printer and mmu firmware as well as the slic3r so it can be changed by filament, but it would be fine if it was just an option in the service menu.

In the beginning there was the word...

Words are meant to be expressive, same applies for names of variables. You are using c and _c in the same local context! Why?

bool home_selector()
{
	 
	int _c = 0;
	int _l = 2;

	for (int c = 5; c > 0; c--)   // not really functional, let's do it rather more times to be sure
	{
		move(0, (c*20) * -1,0);
		delay(50);
		for (int i = 0; i < 4000; i++)
		{
			move(0, 1,0);
			uint16_t sg = tmc2130_read_sg(1);
			if ((i > 16) && (sg < 10))	break;

			_c++;
			if (i == 3000) { _l++; }
			if (_c > 100) { shr16_set_led(1 << 2 * _l); };
			if (_c > 200) { shr16_set_led(0x000); _c = 0; };
		}
	}
	
	return true;
}

The MMU produces quite a hissing sound while idle.
The stepper drivers should enter a reduced power mode while not moving.

There's lots of talk elsewhere about the topic, but it's unmentioned here: differences in hobbed gear size lead to misfeeding of material.

If the first (calibrated) channel is perfect, the second gear is small, you'll end up mm/cm short of primary extruder gears, and get a missed feed.

If you turn up the calibration distance from the "secret menu" to compensate, then you grind filament on the channels with a bigger gear, filling MMU with dust and shavings, and notching filament which causes missed feeds later in the printing process.

This accounts for 60% of my failures.

My top MMU feature requests:
"Home All" command - holding left and right button or similar could make everything home if filament sensor is empty.

"Load Filament" - something to get the filament down the bowden to the printer. This likely has to be in conjunction with the printer (min temp, etc), or just get the filament to the gears and let the printer know there's filament waiting for it.

"Ask printer where I should be" - how often do I see "2>4" on the screen, with the selector on position 3 and filament feeding out of channel 5 into empty space? Often. Most of my manual messing with the machine is trying to get the MMU to match the Mk3's screen.

ANY time there is a misfeed of ANY sort, rehome everything.

Should these be separate topics?

I started another print, which is the same with my previous issue, but this time I forgot to align f2 because the print uses f1 for 4 hours, I couldn't wait that. printer asked for attention, which I did, but the f2 not fully loaded into the nozzle. I immediately pause the print, eject filament, then load filament to nozzle. At this point, I'm unable to load the filament through mmu2 anymore because the idler motor was disabled and wont engage no matter what, while mmu drive motor not moving, as well as the lcd panel stuck at "loading filament x...." while mmu2 not doing anything to load. Even if I were to manually put filament through selector to trigger finda active high, it was no use. Another failed print gone to waste.

I am using MMU2 1.0.3

Hallo,
it might be obvious to most, but I am missing build instructions. e.g. with or without bootloader and if yes which...

thanks
Michael

When using a longer bowden tube, the calibration is taking into account the length, however the point at with the load / unload speed are calculated does not take into account this configured length.

For the UNLOAD this is even worse, as the normal unload towards the FINDA is hard coded for the factory length and with a longer calibrated tube it does not even reach the FINDA, it is pushed forward and pulled in a couple of times (in the error in movement catch-up).

This unnecessarily slows down the total print. On a small MMU print with 1000 filament changes it was more than 2 hours slower as required (measured on my patched firmware), just because the load/unload were soooo slow. (for a stock length tube between mmu2/ mk3 it is not so impacting)

Besides that I noticed in the implementation that delays counters were programmed as floating point numbers, and all timing / distances/accelerations were hardcoded in the logic. I introduced "constants" describing the behavior, but did not refactor the code (some subsequent loops could be optimized) kept the speed and length of the filament to be loaded / unloaded near to the extruder and near to the FINDA the same as original (so slow, same speed as original code) as to not impact the behaviour of the MMU2. Also the merge should be straight forward.

Tested against my own Prusa i3 MK3 / MMU2, firmware MK3 fw. 3.5.1 (unmodified) & MMU 1.03.
Since I used a transparent tube, I could very nicely review where the accelerations / decellerations kicked in, also the "tip"quality can then be reviewed easily.

Note: my bowden tude had an inner diameter of 2.5mm

Will create a pull-request for motion.cpp after one more test.

I am very irritated to report that this new firmware does not address the fact that, upon filament change, the speed setting is reset to 100%, ignoring what was entered in Slic3r. Since I use PETG, 200mm speed causes every single print to fail. How is this not addressed yet???

My selector got stuck during a 2-filament print, and I couldn't find any reason for that.

I tried these without any luck:

• removed cutter blade (even though it looked to sit on the right place)
• filed the selector body a bit, since it rubbed a bit on the MMU body
• greased the spindle and the guiding rods (bad English???)
• Power on reset
• MMU reset

What helped:

• Power Off
• move the selector to the very right end
• Power On

Now the selector is homing correctly again.

Perhaps this is related to prusa3d/Prusa-Firmware#1181

I just reviewed some parts of the code.

the 'move()' function is a bit too simplistic:

void move(int _idler, int _selector, int _pulley)
{
	int _acc = 50;

	// gets steps to be done and set direction
	_idler = set_idler_direction(_idler); 
	_selector = set_selector_direction(_selector);
	_pulley = set_pulley_direction(_pulley);
	

	do
	{
		if (_idler > 0) { PORTD |= 0x40; }
		if (_selector > 0) { PORTD |= 0x10;}
		if (_pulley > 0) { PORTB |= 0x10; }
		asm("nop");
		if (_idler > 0) { PORTD &= ~0x40; _idler--; delayMicroseconds(1000); }
		if (_selector > 0) { PORTD &= ~0x10; _selector--;  delayMicroseconds(800); }
		if (_pulley > 0) { PORTB &= ~0x10; _pulley--;  delayMicroseconds(700); }
		asm("nop");

		if (_acc > 0) { delayMicroseconds(_acc*10); _acc = _acc - 1; }; // super pseudo acceleration control

	} while (_selector != 0 || _idler != 0 || _pulley != 0);
}

A simple but better approximation could be like this:

int delay = 50000;

while(acelerating){
  ...
  sleep_us(delay + minDelay);
  if(delay > 20){
    delay = (delay/4)*3; // which could be even more efficently witten with d2 = d/2; d = d2 + d2/2;
  }else{
    delay = 0; 
  }
}

Here an 1/x function is approximated by an a^(-x) function, which is simpler to calculate, since no division is needed.

Starts with 66% of end speed

Quick calculations in Libre Office show, that the speed for e.g. the idler is "ramped up" from 666 steps/s to 1000 steps/s. That's far away from a proper acceleration. It starts with 66% of the end speed immediately.

No Deceleration

But the larger problem seems to be, that there is absolutely no deceleration implemented!

Inconsistent Speeds

If the function is called with multiple non-zero parameters, the speed steps, when one of them finished it's movement!

Had problems during printing multi colour parts, at first, the problem was that there were blob got stuck into the metal ball and eventually made it stuck triggering the finda as active high. Had that problem resolved by disassembling the selector.

The above was simply the hardware problem, but this particular is pretty much serious from what I think.
During printing, my filament roll had some tangle and the extruder unable to pull properly. It was during the process of changing from f2 to f1, but then, the problem simply unknown. The mmu flashes red at f1, pressing any of the mmu button did nothing (from what I remember), while the main lcd states that the mmu need user attention. The selector were stationed at f2.

I actually not sure how to explain the above problem, why it behaves like that because of filament being tangled eventually steps skipping, but there were no grind marks on the filament either. In the end I had to stop the print midway and it is considered as a failed incomplete prints.

If only that mmu can be reset/reboot by pressing the buttons and then continue the prints without the need of restarting the whole printing process again which is a waste of time and filament usage.

Please revise on how mmu should behave when there are problems.

When printing in single mode, the printer heats up (1-2 minutes), then moves to X0 Y0 Z0.2 and only then asks for which filament to use.
It would be much more convenient to ask which filament to use at the very beginning of the print (right after selecting the file on sdcard).
This happened to me several times that I start the print and forgot to come back selecting the filament. Last time the printer stayed the whole night with the hotend touching the PEI sheet at 240 asking for the filament... This isn't good for the PEI sheet!
The hotend should also timeout and cooldown when no filament is selected after x minutes. I don't want it to start a fire!

Now when the secret is out that the MMU2 firmware is crap and the community needs to fork it to implement basic functionality like proper homing itself: implemented in this fork it is time to get all the functionality to official firmware.

The whole topic was discussed already in this thread: this thread and this is where we want to get

Current version (1.0.3) can't even home properly and is pushing against left wall. The same for 1.0.2 but at least in 50% of cases it aligns against the holes otherwise it is 1-2mm off....

I'm running a print with PVA, I didn't know what temp would've been good for it, so I started running it at 200c per the manufacturer recommendation. But that is too hot, I want to lower it to 195, but the other PLA in the extruder needs to be at 200. There should be a setting available that allows me to change the temp to stay consistent the entire print. It keeps being too hot and isn't forming a proper end so the filament retracts out too far and then it can't load it back in.

Unable to flash the MMU board with firmware 0.9.0 provided together with the last
Einsy firmware 3.4.1
Using Slic3rPE-1.41.1-rc+linux64 and micro USB cable between MMU board and PC.

Installed Einsy firmware 3.4.1 with no problems.

See Slic3r log:

avrdude: Version 6.3-20160220-prusa3d, compiled on Oct 5 2018 at 15:41:54
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

 System wide configuration file is "/tmp/.mount_Slic3roqlBaQ/usr/bin/resources/avrdude/avrdude.conf"

 Using Port                    : /dev/ttyACM0
 Using Programmer              : avr109
 Overriding Baud Rate          : 57600
 AVR Part                      : ATmega32U4
 Chip Erase delay              : 9000 us
 PAGEL                         : PD7
 BS2                           : PA0
 RESET disposition             : dedicated
 RETRY pulse                   : SCK
 serial program mode           : yes
 parallel program mode         : yes
 Timeout                       : 200
 StabDelay                     : 100
 CmdexeDelay                   : 25
 SyncLoops                     : 32
 ByteDelay                     : 0
 PollIndex                     : 3
 PollValue                     : 0x53
 Memory Detail                 :

                          Block Poll               Page                       Polled
   Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
   ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
   eeprom        65    20     4    0 no       1024    4      0  9000  9000 0x00 0x00
   flash         65     6   128    0 yes     32768  128    256  4500  4500 0x00 0x00
   lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
   hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
   efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
   lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
   calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
   signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

 Programmer Type : butterfly
 Description     : Atmel AppNote AVR109 Boot Loader

Connecting to programmer: Found programmer: Id = "CATERIN"; type = S
Software Version = 1.0; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
Device code: 0x44

avrdude: devcode selected: 0x44
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9587 (probably m32u4)
avrdude: safemode: hfuse reads as D8
avrdude: safemode: efuse reads as CB
avrdude: reading input file "/home/andre/Desktop/prusa3d_fw_MMU2board_0_9_0.hex"
avrdude: writing flash (17286 bytes):

Writing | ##########avrdude: error: programmer did not respond to command: set addr
avrdude: error: programmer did not respond to command: write block

***failed;
####################################### | 100% 0.56s

avrdude: failed to write flash memory, rc=-1

avrdude: safemode: Verify error - unable to read lfuse properly. Programmer may not be reliable.
avrdude: safemode: Verify error - unable to read lfuse properly. Programmer may not be reliable.
avrdude: safemode: Sorry, reading back fuses was unreliable. I have given up and exited programming mode
avrdude: error: programmer did not respond to command: leave prog mode

avrdude done. Thank you.

Much of the time the "MMU need attention", it has failed to move to the right channel.

The Selector Drum and the moving carriage get out of sync.

Generally I reset the MMU and try to get it working from there. It is not unusual for me to print a layer or two in the wrong color because the MMU doesn't know what it is feeding. More typical is to spit filament out in the wrong location, poking the unwary Printest in the eye. :-)

Some way to make it fully re-home the mechanicals would make most of these experiences less troubling.

I am not sure if this is a specific problem with my unit or if this is by design or just a code fix...
When not printing, just sitting idle, the MMU2 is fairly loud...! It almost sounds like it has a loud fan running though there obviously isn't one. Is this supposed to happen!? Is anyone else noticing this??

Although the MK3 sensor has problems, it works well for a lot of people. Please enable communication between the MK3 sensor and the MMU2. This would eliminate the need for PTFE calibrations. If a user is confident in their sensor, then they can use it. If they are not, then they can disable it and go back to how it is now.

Also, please enable the cutter. this would eliminate the strings and blobs that cause so many issues.

Mk3/mmu2 only detects filament at mmu2's finda probe. So although filament may be present at the top of the mmu2 and be detected by finda probe - a stringy tip can fail to enter bondtech gears at mk3's extruder.
Another cause for filament failing to reach bondtech gears is mk3/mmu2 relying on a bowden length calibration that was taken when filament was cut perfectly. However during printing the tips are not perfect, they can be very stringy which throws off the bowden length measurement the mk3/mmu is relying on.

Since the printer has no way to detect or prevent this issue it keeps printing, unaware that filament did not print = layer skips

(mmu2 comes in kit form, so it should account for different build tolerances, perhaps a total measure of filament path resistance from spool to bondtech extruder > pass or fail displayed to user

There are dozens if not hundreds of brands of filament. Seems the mmu2 is expecting a level of consistency from all brands of filament rather than being flexible enough to work with all filament. But I've had issuses with even prusa filament and stringing. So rather then expecting perfect tips from every filament - shouldnt the mmu2 actively detect filament making it into the bondtech gears > ask user to fix issue if no filament present)

prusa3d/PrusaSlicer#1333

prusa3d/Prusa-Firmware#1265

I'm not sure what it takes to get SOMEONE at prusa to say "Yes, we're willing to talk about this"... But it seems like if people don't post something 12 times in 15 places, it gets ignored.

This makes more reading for the devs than if you just answered the posts. WE as users don't know what you're working on, all we see is our notifying the development team there are issues and we get nothing but put off. If the issue is "being considered by the firmware team" why isn't there an open issue for it?

Quoting:
Slicer Ver:
1.41.1

Operating system type + version
Win10x64/NA

Behavior
Slice a print using MMU Single compatible printer. Initiate print.
Printer preheats, mesh levels, moves back to home and then asks you for the material.

I have had this lead to my coming back 16 hours later with the bed cooking at 85 degrees and nothing has happened. Many, many many times I've forgotten for a shorter period of time, and in general it means sitting in front of the printer watching it do nothing for 5-10 extra minutes per print.

It would be great if the slicer and/or printer could conspire to ask you which channel you want to use as soon as you select the file.

Not to double up, but I would also like to be able to set the channel in the slicing/on the PC

Is this a new feature request?
Yes?

As reported there prusa3d/Prusa-Firmware#1240
There should be some procedure to eject the filament, when FINDA is active on bootup. This must be implemented in both firmwares.

I think it could work like this:

• MMU2 detects filament on bootup in FINDA
• home the idler only
• tell the printer to start and eject procedure
• ask user what to do: (a) heatup and eject (b) manually fix
• if (a):
  • ask for channel of filament and
  • ask optional for type of material (for proper temperature)
  • heatup the nozzle
  • do a proper ramming and eject
  • put the filament back into its parking position
• home the selector

The behavior of canceling a print from the LCD (when printing from and SD card) acts as expected: the print stops, and then the printer unloads the filament from the hot end back to MMU. When a cancel print command is recieved from Octoprint (likely from other USB sources as well, but not confirmed) it stops the print but fails to unload the filament back to the MMU, causing a jam.

Q1: Did you test the MMU2 controller on the MK2.5 miniRAMbo?

• P3 connector pin 9 on an Einsy is 'PJ5' (pin76) but on the miniRAMbo this pin is 'reset'.
  • I think there is a need for a y-cable for the MMU2 signal cable, similar to the MK2.5 P.I.N.D.A. v2 and Noctua.
  • Opened a pull request for Prusa-firmware prusa3d/Prusa-Firmware#1024

Q2: As the MK2.5 runs on 12V vs. MK3 24V, do you need to adjust the power/current/settings for the MMU2 TMC2130s?

In my case, the filament got stuck in the extruder bowden hose, and the filament got ground to the half diameter in the MMU. It reseted in that situation for at least one hour, even though I was in the room nearby, but didn't notice the problem.

Rebooting the MMU can cause it to go down the menu - flashing LED5, flashing LED4, then they all light up green for a bit, then just LED1. No movement.

Then nothing mechanical moves, buttons don't do anything except move lights around. I can reboot it over and over, and just get all green lights.

Motors stay cold and quiet.

I'm on the "new" firmware which lets you calibrate bowden tube length per channel. I've had hard to define problems since upgrading to it.

since this is a lengthy process, it is very annoying. considering how many users are out there, this should really be optimized.

I assume, the MK3 is sending some command to the MMU to rehome, right? How about homing on that command only?

Greets, Karl

A FULL descirption of the state of the lights and the MMU would be super useful.

When is a blinking light mean loading? When does the left button unload?

OFTEN I find the MMU in an unusable state - filament sticking out a hole without the selector present, etc.

It can be very difficult to make the MMU do something on purpose, like attempt to load filament, etc. Perhaps it could use some reworking, but just staring and blinking lights it's hard to tell what's even SUPPOSED to be going on.

It is hard to make meaningful suggestions when it's unclear what is happening. I've gotten links to small bits of information that explain how certain procedures work - but never what ALL THREE BUTTONS actually DO in a particular state, how you get in and out of a state, etc.

Something definitive would be a big help!

Hi!

Subj...

Often the issue that I have is the drum losing its home, or the selector.

Moving the selector to the far right (past #5 - with both flashing lights on 5) could/should rehome everything, and have the MMU ask the printer what it's supposed to be doing.

I would suggest re-initializing the stepper drivers as well, here, since oftentimes in this state one or more of the motion components are unresponsive.

When filament is ejected (and still not removed by the user), the push buttons are still reacting to move the selector, which could lead to a filament-slector-crash.

Version V1.0.1

I think I posted in the wrong branch:
prusa3d/Prusa-Firmware#1190

posting this here as this is correct place for mmu2 firmware issues
https://manual.prusa3d.com/Guide/Service+menu+-+bowden+length/821?lang=en
After doing bowden length calibration. U exit service menu by hitting reset on mmu.

So goto sd card, choose a print. Printer will begin heating up nozzle and bed, then do bed calibration. Once bed calibration is done, it fails to load filament.

Solution 1 (tried it)
I have to reset printer by hitting reset on mk3. Then print from sd card again.

Solution 2 (haven't tried it)
Just print from sd card a 2nd time. (Chris Riley's, live stream build of mmu2)

Im not sure if this was posted before, but if you are for example printing PLA and PETG at the same time and you switch from PETG back to PLA, the printer wants to purge the rest of the PETG in the extruder at 205°C with PLA resulting in a failure.

Please add the possibility to purge with the temperature set in the profile of the last loaded material.

When a print is started over Octoprint from a remote location and there is a problem with MMU there is no way to cancel the print or turn off heaters. The terminal shows "Paused: waiting for user input" posting every 2 seconds with no automatic shutdown. This can leave heaters on for long periods if there is no one to push the knob. Even trying to disconnect the serial connection is not allowed. The only workaround I've been able to do is SSH into the pi and force a reboot from the command line. The printer resets after Octoprint is able to reconnect which turns the heaters off. The problem with this is that I loose the print in whatever state it was in during the failure.

I feel this is a safety issue that should happen automatically. The extruder heater already turns off when the MMU needs attention, but there's no reason the bed should also be left on if there is no user input after say half an hour.

I thought that this had only to be done one time with one filament and then I had the surprise to see that this is depending on the filament number. I don't know why, as the lenght concerned is the lenght on the orange tube, which is the same for all filament but OK : 5 filaments, 5 parameters to tune (isn't it an old code design from MMU1 ?).

Then I tried to tune all these parameters : setting the pfte tube length for the 5 filaments but, when I reset the mmu2, only the last filament i tuned has the corrects length value. So i had to do it 5 times, one per filament.

It would be great to be able to do the 5 at once. (And is only one parameter suffisant ?)

Sorry for my english, i'm french (and tired, it's late).

Calibrating the tube length depends on what you're feeding. I can get PLA or PETg to feed and always end up within 1-2 mm on the hobbed gear, but feeding TPU will fall well short (not visible, about 1.5cm short).

I feel that when the printer is printing with a TPU, and knows it, it compensates? I certainly was BARELY getting anything out of the printer, the entire purge was extruding air, then it would pick up as I got to the object.

What I'm wondering is if I need to recalibrate all 5 channels every time I change filament material. If so, it speaks to having a multiplicative constant for each channel, then setting one overall would scale the rest?

Allow auto-deplete to use less than all 5 filaments to enable it's use on prints that are running with soluable support or other use cases where you would want it to use up a spool but not cycle through all of the available spools.

A possibility would be when enabling auto-deplete, have all lights on the MMU2 flash red, and the user select which filament slots to use for auto deplete by cycling left or right and middle button clicking to turn the light(s) green for selection. Another option is just have them select how many slots to use for auto deplete from left to right or right to left.

This feature is the most useful for the most expensive materials which you wouldn't want to waste the end of a spool, such as BVOH, but is currently useless in this type of situation.

Currently the middle button is checked after homing, which takes quite a while. Please let us move this if-statement before calling home().

	home();
	tmc2130_init(0); // trinamic
	
	// check if to goto the settings menu
	if (buttonClicked() == Btn::middle)
	{
		setupMenu();
	}

Further reviewing the code reveals this strange behaviour:

bool home_idler()
{
	int _c = 0;
	int _l = 0;

	for (int c = 1; c > 0; c--)  // not really functional, let's do it rather more times to be sure
	{
		move(0, (c * 5) * -1,0); // <<== WHY moving the selector in a function called 'home_idler()'???
		delay(50);
		for (int i = 0; i < 2000; i++)
		{
			move(1, 0,0);
			delayMicroseconds(100);
			tmc2130_read_sg(0); // <<== Stall Guard is read out, but result is ignored?

			_c++;
			if (i == 1000) { _l++; }
			if (_c > 100) { shr16_set_led(1 << 2 * _l); };
			if (_c > 200) { shr16_set_led(0x000); _c = 0; };
		}
	}
	return true;
}

Current version in 51aea86

void park_idler(bool _unpark)
{

	if (_unpark) // get idler in contact with filament
	{
		move(idler_parking_steps, 0,0);
		isIdlerParked = false;
	} 
	else // park idler so filament can move freely
	{
		move(idler_parking_steps*-1, 0,0);
		isIdlerParked = true;
	}
	 
}

If the caller doesn't check properly, if the pully is engaged or not, the idler gets out of sync and could do the parking or unparking motion twice (!!!). I haven't checked, if all the calls of that function ensure a proper state of isIdlerParked, but that's a nogo!

Suggested code:

First I would rename the function and argument, so we get rid of dumb negations to
void engage_filament_pully(bool engage). Then I would check for the current state of the idler before moving it.

/**
 * @brief engage_filament_pully
 * Turns the idler drum to engage or disengage the filament pully
 * @param engage
 * If true, pully can drive the filament afterwards
 * if false, idler will be parked, so the filament can move freely
 */
void engage_filament_pully(bool engage)
{
	if (isIdlerParked && engage) // get idler in contact with filament
	{
		move(IDLER_PARKING_STEPS, 0, 0);
		isIdlerParked = false;
	} else if(!isIdlerParked && !engage) // park idler so filament can move freely
	{
		move(IDLER_PARKING_STEPS * -1, 0, 0);
		isIdlerParked = true;
	}
}

It would be great if you could load the machine with the MMU, then put it in 'bypass' mode.

Typically you can just reach in the back and rotate the selector drum to where it doesn't drag, but it would be nice to run my old, non-MMU aware sliced g-code.

Right now you can select filament, and pre-load it ('prime the mmu'?) - but you can't get it to the nozzle.