load / unload filament do not take into account the calibrated bowden length, fixing this on a long MMU job saved 2.5 hours printing time

[ruedli]

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.

[KDanielK]

I also suggest the possibillity to change the load/unload speed. Especially the unload since the fast part sounds like grinding/rattling while the slower part sounds rly smooth.

[ruedli]

Hi, on the speed: well, it is easy to adjust in the firmware, in the pull request I put the values for load/unload speed at the speed that Prusa used originally.

I put the speed about twice as high, see comments in the adapted firmware, (in my pull request). Original delays were 650 us for load and (pushing) 550 us for unload (pulling), I used 350 us and 250 us.

The filament flashes in and out, and brakes just-in-time, as you can see in my youtube movie here:

https://youtu.be/3qj8hQHOsOM

Because I use a long and fully transparent MMU-extruder bowden, you can actually see the filament moving, it is quite entertaining!

Now... there is no grinding rattling from the pulley... but: my mounted selector springs take care of syncing between extruder and pulley pushes. As you can see, towards the end the (spring loaded) selector moves up, because the pulley pushes filament further in where the extruder is not picking it up yet fast enough. then, when the pulley is released through the idler, the pressure is released and the extruder is fully in control.

When you do not have the springs, you get grinding I quess, which is bad, as the extruder then risk having less grip lateron.

So: from my experience grinding does not depend on pulley speed for loading/unloading. I guess with flex filament high speed is a no-go, so THAT would be a good extra thing to implement: when the material is FLEX, lower speeds should be used.

With the spring mounted slector mod, I feel the filament change is much improved, just two long screws with ball point springs, that was it... BE CAREFUL not to screw into the FINDA with the upper screw though!

I got the mod from the Prusa Forum.

Cheers Ruud

Op zo 30 dec. 2018 om 09:57 schreef KDanielK notifications@github.com:

I also suggest the possibillity to change the load/unload speed. Especially the unload since the fast part sounds like grinding/rattling while the slower part sounds rly smooth.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/MM-control-01/issues/100#issuecomment-450547425, or mute the thread https://github.com/notifications/unsubscribe-auth/AExsOOEhFXgrWM4xVt_NLBiYF3efP46Nks5u-IADgaJpZM4ZjLzM .

-- Ruud Rademaker prefered mail: ruud.rademaker@gmail.com

[KDanielK]

Hi, I only have the ratteling/slipping mid-way in the bowden when the travel is really fast. Not in the slow beginning or the end only the fast middle part. When i trouble shoot without the bowden I can't hold back the filament during the slow unloading travel but when it goes fast its really easy to hold it back. In the early days of the prusa extruder they used a gear + bearing but now we have two gears since its way better. In the MMU there is a gear + bearing and it slips in high speeds.

[ruedli]

I see, understand you better now, but to make sure:

do you have the slipping at the normally configuerd by Prusa speeds? Or just when you use the ultra fast speed, as I patched in the firmware?

If you have it also in the Prusa firmware, is there something wrong in your setup perhaps? Is your filament path in the MMU aligned EXACTLY to the middle of the pulleys? This must be done quite precise. If not properly aligned, the filament is not in the groove and might slip easier.

Or- is your filament slippery by itself?

Or- Is your idlers properly aligned and can your bearings in the idler freely rotate?

When the filament is in the MMU, but not in the extruder (take out the bowden at the end of the extruder), you should be able to move it freely when the idler is parked, and it should be fairly difficult to move when the idler is engaged.

As you can see from my video, the speed that Prusa uses is much lower than what I use currently and there is no slip whatsoever. I cannot "easily" move the filament when it is pushed in. When it is extruding, only the extruder pulls in the filament, not the MMU, so that is not a good test.

In short: I think that when you observe slipping filament when the MMU operates it, you should check it out and perhaps contact the Prusa chat box, post a video perhaps on the rattling sound you hear...

Success, Ruud

Op zo 30 dec. 2018 om 20:33 schreef KDanielK notifications@github.com:

Hi, I only have the ratteling/slipping mid-way in the bowden when the travel is really fast. Not in the slow beginning or the end only the fast middle part. When i trouble shoot without the bowden I can't hold back the filament during the slow unloading travel but when it goes fast its really easy to hold it back. In the early days of the prusa extruder they used a gear + bearing but now we have two gears since its way better. In the MMU there is a gear + bearing and it slips in high speeds.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/MM-control-01/issues/100#issuecomment-450581708, or mute the thread https://github.com/notifications/unsubscribe-auth/AExsOChLC80yrWOVP7itcSUudZC-IS6Eks5u-RT0gaJpZM4ZjLzM .

-- Ruud Rademaker prefered mail: ruud.rademaker@gmail.com

[KDanielK]

Hi, thanks for taking the time with this issue :)

I have this problem with the stock-firmware and speeds. I should mention that I have the 2.5 (12v) setup and this might be a issue since the motors dont have enough pull?

Everything is aligned, I have double and tripple-checked. I also can move the filament freely when idlers are parked. My idlers were a bit missaligned, this alignment was not part of the manual so I added a note to it a few minutes ago.

I think the main issue is that the filament sometimes get a plug in the end (gets a little bigger in the cooling area of the extruder) and this friction is to high for the speed and the rly narrow bowden tube. I see many in the forums suggesting getting a 2.5mm inner diameter PTFE for the bowden drive to solve this and that might be the best resolution.

If you remove the bowden and do a "load to nozzle" and then do a "unload" can you restrain the filament by hand during the unload? For me this impossible during slow speeds but simple in high.

[ruedli]

I see, will try do do the unload/load without the bowden, but now I need to wait until my 12 hours MMU print is finished. Indeed, the 12V could reduce power a lot!

In this case a 24V step up convertor to bump up the voltage of the steppers would surely help! In fact I believe the trinamic drivers are not able to push enough current in at 12V for their fancy driving modes, so you loose a lot of torque...

Maybe this upgrade 12V->24V for the MMU using a 5$ step-up convertor should be considered by Prusa, but that is a different discussion.

Frther: I use indeed 2.5mm inner diameter bowdens, combined with the "spring-loaded" selector and a slight amount of extra calibrated length, because with the 2.5mm there is more variance of where the filament ends when pushing. This will surely make a difference if your filament has a thickened part, which mine has most of the time, but the 2.5 mm take care of it. Also, it could be that your orange bowden tube is slight damaged/flattened, so that could create a narrow part in the tube.

If you want to further discuss it, I suggest to take it in the forum, as this thread will more focus on the firmware / software part. your input on the 12V consideration is most valuable however and Prusa needs to consider this, especially when they decide to up the speed, like I have for the MK3. Ultimatyely, MK2.5 and MK3 might need different profiles, depending on the 12V / 24V availability. I you compile my change, setting the speed lower is very easy (lowers speed means you need values, they are delays between the pulses). If you want me to compile a version with low speed, send me a private mail and I will mail it to you,

Note that for the pull request as I submitted, I did not increase speed for the stepper, I just made them stop "just before" the end of the bowden when loading and unloading and that is what gave the speed change. Privately I pushed it further and faster, as my video shows...

Have fun,

ruud

Op ma 31 dec. 2018 om 10:24 schreef KDanielK notifications@github.com:

Hi, thanks for taking the time with this issue :)

I have this problem with the stock-firmware and speeds. I should mention that I have the 2.5 (12v) setup and this might be a issue since the motors dont have enough pull?

Everything is aligned, I have double and tripple-checked. I also can move the filament freely when idlers are parked. My idlers were a bit missaligned, this alignment was not part of the manual so I added a note to it a few minutes ago.

I think the main issue is that the filament sometimes get a plug in the end (gets a little bigger in the cooling area of the extruder) and this friction is to high for the speed and the rly narrow bowden tube. I see many in the forums suggesting getting a 2.5mm inner diameter PTFE for the bowden drive to solve this and that might be the best resolution.

If you remove the bowden and do a "load to nozzle" and then do a "unload" can you restrain the filament by hand during the unload? For me this impossible during slow speeds but simple in high.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/MM-control-01/issues/100#issuecomment-450624264, or mute the thread https://github.com/notifications/unsubscribe-auth/AExsOPi2zCi0-U592SvZ5PRqd0zPNr8dks5u-dfHgaJpZM4ZjLzM .

-- Ruud Rademaker prefered mail: ruud.rademaker@gmail.com

[KDanielK]

It works like a charm using a wider ptfe-tube. I think that you perhaps should make it clear that this pull request will most likely not work with a stock MMU and would require a ptfe-upgrade.

Great work

[ruedli]

Great that it works as intended for you KDanielK. You could now even try higher speeds ;-)

I am not sure why it would not work with your stock PTFE, because I made the pull request with the same speed settings as what they were before: 650 (pushing) and 550 (pulling). I only modified the length over with it pulls, taking into acount the configured bowden length.

Anyhow, Prusa should review and test with the information they have now from both our setups.

In the mean time I did the "pull" and "hold filament"check that you suggested using my fast speed settings (under 24V). If I hold the filament loosely, the motor pulls it in, even at high speed. When I hold the filament firmly, I can stop the movement when the motor is pulling at high speed, but not when it is pulling at low speed.

Looks similar to what you get? So: the filament in the stock PTFE might be problematic, especially when the tip of the filament is slightly thicker.

I also checked the design of the MMU board. The scema connects 24V just to the stepper drivers. I therefore assume that if you up the 12V to 24V using a step-up converter before the 12V enters the MMU2 (found one for less than 3$ on Aliexpress, item 32832823055) it could improve the behaviour of the steppers. The currents are not that high, in fact there is a 750mA fuse in the 24V input, so it cannot be more then that!

Op di 1 jan. 2019 om 12:06 schreef KDanielK notifications@github.com:

It works like a charm using a wider ptfe-tube. I think that you perhaps should make it clear that this pull request will most likely not work with a stock MMU and would require a ptfe-upgrade.

Great work

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/MM-control-01/issues/100#issuecomment-450722544, or mute the thread https://github.com/notifications/unsubscribe-auth/AExsOEKh8FaJ6SGLZCW9lY3YnX-acZDpks5u-0EjgaJpZM4ZjLzM .

-- Ruud Rademaker prefered mail: ruud.rademaker@gmail.com

[KDanielK]

"I am not sure why it would not work with your stock PTFE, because I made the pull request with the same speed settings as what they were before: 650 (pushing) and 550 (pulling). I only modified the length over with it pulls, taking into acount the configured bowden length."

Sorry, I was not clear here. I hardly worked with stock speeds since the tube is to narrow, with your even higher speeds it would fail even harder. I think prusa should supply a 2.5mm bowden tube since the stock one is causing so much problems. Have you tried your pull request with the stock bowden? :D

Nice to see that you can confirm my findings about how the filament slips easier in high speeds, this is not a issue with the larger tubing but with the stock one ofc.

The suggestion from me is that your pull-request should come with a "Do you have a 2.5mm bowden" verification of some kind before ppl try to use it. Maybe as a firmware setting

BR/Daniel

[ruedli]

Have you tried your pull request with the stock bowden?

Well, that is no longer an option for me, since a dog started chewing on it and damaged it beyond repair ;-(

When you mention:

I hardly worked with stock speeds since the tube is to narrow,

Does this mean you patch the firmware yourself each time that you upload it?

Indeed, my choice would also be 2.5mm for the bowden. It is specified as 2mm. I can only speak for "my MK3" with "my MMU2", though.

[KDanielK]

Mine was closer to 1.8, I switched to a 2.0 and that worked way better and I expect the 2.5 (from ebay) will work even better. I measured the bowdens supplied in the mmu2 (5 for filament and 1 for bowden) and they had a mix of id where some would hardly get a new filament through and other had room to spare (1.8 vs 2.0). The stock bowden was rly tight (I got the clear one)

[ruedli]

I see, mine is ID 2.5 as well, I also tried with ID 3.0. This also worked, but the distance when pushing the filament in is not so reproducible.

Where tight ID is super important when you use a bowden extruder, I feel with a filament changer it is mainly causing problems, because the filament tip is not properly shaped etc. Having some "extra" push in allowing the extruder to grab the filament with an larger inner diameter works more reliable in my setup...

[ruedli]

Daniel, I am really puzzled with the behaviour of the Travis build, which now succeeds, all depending on ONE line in my permanent_storage.cpp. This SHOULD refer to previous_extruder, which is what builds fine for the arduino build, but I can opnly pass the test if I put it to active_extruder.

Since you also tested my pull request: Can you see what is wrong? Why can I not use previous_extruder, but do I HAVE to use active_extruder, just to pass the Travis integration build test????

Both are defined and used in the same manner as global external int in mmctl.h as far as I can see.

You can see the error on the failing builds with the commits before my (last) successful build on the pull request page...

[KDanielK]

Hi again, I did a local build not using travis... I have reviewed the code though and the integration tests seems to be in a early state. I could help you narrow this down but

1. Why is there a mmctrl.h in the test-folder?
2. A new declaration of the global variable int active_extruder in permanent_storage_test.cpp ?

I'm not really into global variables in c++, they cause to many issues and the code gets hard to read :P

[ruedli]

Hi Daniel,

Well, that is a good catch. I did not notice these in the tests folder -I reviewed all the files in the MM-control-01 folder and assumed that was the complete set. I did not personally create anything there or modified them. In the Arduino build they are not sourced in as far as I can see, so... what is the purpose of the "tests" folder?

Indeed, when I check the Travis build, it invokes test.sh and in their is the build line:

cmake -G "Eclipse CDT4 - Ninja" ../MM-control-01/Tests || exit 3

After that line there is what seems to be the normal build...

All lines in test.sh are from Marek Bel, so,,, he could perhaps shed light on that??? In the mean time I will reinstate my pull request as it was meant to be (using previous)extruder, as in the MM-control-01/mmctrl.h that one IS defined as a gobal variable. I will also make a "quick and dirty" patch and introduce previous_extruder in the same scope as how they define "active_extruder" in this Tests folder.

Wished there would be more info on "what is what - for which reason - and what purpose"...

Thanks a lot for tracking this one, you surely helped me!!! I was doubting all my skills as I couldn't nail it down, and seems like the classical: looking for the error in the wrong file, where the error was not in...

Do you notice something I overlooked and should be taken into account? To me the failing Travis build is an issue of the Travis build and the assumptions they make to the main sources and the way they redifine the globals into locals.. I feel they are not related to my pull request, but will attempt to fix things here, as this Travis build is unpleaing me.. I assume the files in the "tests" folder are not used in the actual generated firmware..... The Prusa guys can explain me how these files need to be maintained, it was not clear to me...

So... thanks again!

;-)

Cheers Ruud

Op wo 2 jan. 2019 om 19:13 schreef KDanielK notifications@github.com:

Hi again, I did a local build not using travis... I have reviewed the code though and the integration tests seems to be in a early state. I could help you narrow this down but

1. Why is there a mmctrl.h in the test-folder?
2. A new declaration of the global variable int active_extruder in permanent_storage_test.cpp ?

I'm not really into global variables in c++, they cause to many issues and the code gets hard to read :P

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/MM-control-01/issues/100#issuecomment-450939003, or mute the thread https://github.com/notifications/unsubscribe-auth/AExsODgy6uqejYxOHUX2aX7pag5dBx5Qks5u_PbDgaJpZM4ZjLzM .

-- Ruud Rademaker prefered mail: ruud.rademaker@gmail.com

[ruedli]

So... made the Travis build work, now I knew where to look thnx KdanielK for putting me on track,, this was not so difficult anymore...

pull request #101 is now clean afa I can see...

[dcwalmsley]

Just noticed this posting. I have a HyperCube with the MMU2 installed. My main board is a Einsy board powered off 24vdc.

I ran into a issue with calibrating my filament length from 360mm (orange Prusa filament shipped with MMU) o my Capricorn tubing measuring 565mm overall.

So I followed the instructions in the handbook provided and noted that I could not advance the filament all the way to the end of the tubing. Suspected code didn't account for guys like me going beyond their idea of maximum calibration length.

Where do I go to get the modified MMU2 code to allow me to flash the unit to take advantage of the longer length?

Thanks,

~Doug W

[ruedli]

Hi Doug,

The stock MMU 2 version 1.03 has a fix for that, the maximum length is now 792 mm. Can you confirm the version of the MMU2 software you are using? In fact, I know this, because the code for making it longer is what I contributed to 1.03, as I ran into it as well, I modified the constant in permanent_storage.cpp, this now reads:

static const uint16_t eepromBowdenLenMaximum = 16000u; //!< Maximum bowden length (~792 mm)

Alternatively you can also compile my fork, as provided with pull request

101 and enjoy better management of pulling in filament (and increase the

speed further if you modify the constants)

These files are currently here: https://github.com/ruedli/MM-control-01/tree/load_reload_using_bowdenlength

Cheers Ruud Cheers Ruud

Op di 15 jan. 2019 om 22:41 schreef Doug Walmsley <notifications@github.com

:

Just noticed this posting. I have a HyperCube with the MMU2 installed. My main board is a Einsy board powered off 24vdc.

I ran into a issue with calibrating my filament length from 360mm (orange Prusa filament shipped with MMU) o my Capricorn tubing measuring 565mm overall.

So I followed the instructions in the handbook provided and noted that I could not advance the filament all the way to the end of the tubing. Suspected code didn't account for guys like me going beyond their idea of maximum calibration length.

Where do I go to get the modified MMU2 code to allow me to flash the unit to take advantage of the longer length?

Thanks,

~Doug W

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/MM-control-01/issues/100#issuecomment-454562325, or mute the thread https://github.com/notifications/unsubscribe-auth/AExsOKPZWvTEgn1PgfXxKXMZqFHI3obkks5vDksLgaJpZM4ZjLzM .

-- Ruud Rademaker prefered mail: ruud.rademaker@gmail.com

[dcwalmsley]

Hi Ruud,

I flashed Prusa's MMU2 version 1.0.3 this morning. Does theirs accommodate faster speeds as indicated in your post? If not I will download yours compile and reflash it.

Thanks for getting back on this.

Best Regards, Doug W.

On Wed, Jan 16, 2019 at 5:32 AM Ruud Rademaker notifications@github.com wrote:

Hi Doug,

The stock MMU 2 version 1.03 has a fix for that, the maximum length is now 792 mm. Can you confirm the version of the MMU2 software you are using? In fact, I know this, because the code for making it longer is what I contributed to 1.03, as I ran into it as well, I modified the constant in permanent_storage.cpp, this now reads:

static const uint16_t eepromBowdenLenMaximum = 16000u; //!< Maximum bowden length (~792 mm)

Alternatively you can also compile my fork, as provided with pull request

101 and enjoy better management of pulling in filament (and increase the

speed further if you modify the constants)

These files are currently here: https://github.com/ruedli/MM-control-01/tree/load_reload_using_bowdenlength

Cheers Ruud Cheers Ruud

Op di 15 jan. 2019 om 22:41 schreef Doug Walmsley < notifications@github.com

:

Just noticed this posting. I have a HyperCube with the MMU2 installed. My main board is a Einsy board powered off 24vdc.

I ran into a issue with calibrating my filament length from 360mm (orange Prusa filament shipped with MMU) o my Capricorn tubing measuring 565mm overall.

So I followed the instructions in the handbook provided and noted that I could not advance the filament all the way to the end of the tubing. Suspected code didn't account for guys like me going beyond their idea of maximum calibration length.

Where do I go to get the modified MMU2 code to allow me to flash the unit to take advantage of the longer length?

Thanks,

~Doug W

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/prusa3d/MM-control-01/issues/100#issuecomment-454562325 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AExsOKPZWvTEgn1PgfXxKXMZqFHI3obkks5vDksLgaJpZM4ZjLzM

.

-- Ruud Rademaker prefered mail: ruud.rademaker@gmail.com

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/MM-control-01/issues/100#issuecomment-454730793, or mute the thread https://github.com/notifications/unsubscribe-auth/AFZdGrM4gxE3K3P815N9joCAllPHbmugks5vDv_EgaJpZM4ZjLzM .

-- Thanks,

Doug W.

[ruedli]

No, with a longer PTFE, the stock 1.03 will take much longer when unloading, because it assumes a standard length PTFE and after reaching that point moves very slowly. My version in the pull request unloads faster, by using the "normal" unload speed for the whole length.

If you want it even faster, you can adjust the speed itself by adjusting the parameters. I left comments as to what I personally uses. Then the filament flies in and out real fast, but just before getting to the end of the movement, it adjusts to the speeds used by Prusa.

If you use a transparent PTFE, you can see the effect nicely, as in my posted video for instance.

Op wo 16 jan. 2019 15:21 schreef Doug Walmsley <notifications@github.com:

Hi Ruud,

I flashed Prusa's MMU2 version 1.0.3 this morning. Does theirs accommodate faster speeds as indicated in your post? If not I will download yours compile and reflash it.

Thanks for getting back on this.

Best Regards, Doug W.

On Wed, Jan 16, 2019 at 5:32 AM Ruud Rademaker notifications@github.com wrote:

Hi Doug,

The stock MMU 2 version 1.03 has a fix for that, the maximum length is now 792 mm. Can you confirm the version of the MMU2 software you are using? In fact, I know this, because the code for making it longer is what I contributed to 1.03, as I ran into it as well, I modified the constant in permanent_storage.cpp, this now reads:

static const uint16_t eepromBowdenLenMaximum = 16000u; //!< Maximum bowden length (~792 mm)

Alternatively you can also compile my fork, as provided with pull request

101 and enjoy better management of pulling in filament (and increase the

speed further if you modify the constants)

These files are currently here:

https://github.com/ruedli/MM-control-01/tree/load_reload_using_bowdenlength

Cheers Ruud Cheers Ruud

Op di 15 jan. 2019 om 22:41 schreef Doug Walmsley < notifications@github.com

:

Just noticed this posting. I have a HyperCube with the MMU2 installed. My main board is a Einsy board powered off 24vdc.

I ran into a issue with calibrating my filament length from 360mm (orange Prusa filament shipped with MMU) o my Capricorn tubing measuring 565mm overall.

So I followed the instructions in the handbook provided and noted that I could not advance the filament all the way to the end of the tubing. Suspected code didn't account for guys like me going beyond their idea of maximum calibration length.

Where do I go to get the modified MMU2 code to allow me to flash the unit to take advantage of the longer length?

Thanks,

~Doug W

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/prusa3d/MM-control-01/issues/100#issuecomment-454562325

, or mute the thread <

https://github.com/notifications/unsubscribe-auth/AExsOKPZWvTEgn1PgfXxKXMZqFHI3obkks5vDksLgaJpZM4ZjLzM

.

-- Ruud Rademaker prefered mail: ruud.rademaker@gmail.com

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/prusa3d/MM-control-01/issues/100#issuecomment-454730793 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AFZdGrM4gxE3K3P815N9joCAllPHbmugks5vDv_EgaJpZM4ZjLzM

.

-- Thanks,

Doug W.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/MM-control-01/issues/100#issuecomment-454796026, or mute the thread https://github.com/notifications/unsubscribe-auth/AExsOKYzIJtkpSnb_7HfgJBw-jXuZLA9ks5vDzVTgaJpZM4ZjLzM .

[mkbel]

Already fixed in 4d7d513