Feature request for MMU2/MMU2S: Integrate Skinnydip string reduction into PrusaSlicer

[domesticatedviking]

I'm the author of the Skinnydip string reduction post processing script, and would like to assess the interest of having the core features of skinnydip integrated into PrusaSlicer.

The two most critical features of skinnydip are:

• the ability to set a toolchange temperature prior to filament being extracted from the hotend.
• a quick secondary "dip" into the melt zone after cooling moves finish, to burn off any fine threads that remain on the tip of the extracted filament.

I am an intermediate hobbyist coder who would need to extend his skillset a bit in order to write these functions into Slic3r. I'm willing to put together a pull request if the official devs are interested in these features being added. Some guidance would also be much appreciated.

[UlwaziSA]

excellent idea

[TheMrCaveman]

Would love this to be integrated!

[domesticatedviking]

Coming soon to a pull request near you:

[MrMap]

I do get the impression (from FB groups) that the interest for Skinny Dip is much higher than what the likes count here on Github indicates. I hope Prusa will pay serious attention the possibility of including Skinny Dip into the Prusa slicer. The MMU2S system needs every improvment it can get to make functionality more robust and reliable.

[bubnikv]

We have evaluated the skiny dip technique and in our opinion it did not improve reliability, it only increased the print times.

@rtyr knows more details.

[MrMap]

@bubnikv Thank you for prompt response! Interesting news for me, I did not know. Of course it would be much appreciated if @rtyr would care to elaborate briefly on the findings here.

[domesticatedviking]

We have evaluated the skiny dip technique and in our opinion it did not improve reliability, it only increased the print times.

Appreciate the response. I would be interested to know about your testing methodology. I respect that Prusa has to make decisions about which features to include and which features to omit, and that you are pulled in many directions with respect to how you spend your time. If it came to a choice between integrating this feature and implementing a plugin manager, for example, I would wholeheartedly support you spending your time working on the latter.

I will say this, though -- from a UX perspective, Skinnydip just works. The current tip-shaping options exposed in Advanced Filament settings are needlessly complicated, and running through all these settings to find out which of them actually helps with tip forming is an exercise that is leaving many MMU users bewildered and frustrated. If nothing else, I would suggest that the variables should be grouped according to the types of tip formation issues they can be used to resolve. Personally, I have not been able to isolate the impacts of those variables, and users are beginning to suspect that Prusa doesn't really understand their impacts either. In particular, the issue of oversized tips is one that users are struggling to resolve through the exposed settings.

I am convinced that quite often the tips becoming too large is due to compression of the PTFE lining the heatsink, and the evidence I give for this claim is the incredibly consistent diameter tips I get when I use one of David Shealey's custom machined Torlon heatsink inserts.

Anyway, that's all from me on this issue. I never really expected Prusa to adopt this because I'm sure there isn't a consensus about MMU2 issues at HQ any more than there is in the community. But I do look forward to the day when the community will be able to make its own decisions about which features it sees valuable enough to implement, ideally via a plugin manager of some kind.

Thanks for making a product that was good enough for me to care about this much, bubnikv! Peace!

[rtyr]

Hi. I did some testing of your skinnydip post-processor in March. It was the latest beta version with default settings. I tried several variants (lower temperature+dip, dip only, lower temperature before unload only, my own test based on findings). As you can see from attached photo, skinnydip technique alone did not produce better filament tips for me (quite the opposite), at least with PLA filament brands used (from left: Chinese noname, Gembird, Prusament, Plasty Mladeč, Fillamentum). Surprisingly, I saw bigger positive impact from the "lowering temperature" part of your PP script. Later I discovered, that it is more about the delay created before the initial unload. So I made one additional test with stock ramming sequence and short pause before the initinal unload. Filament tips on the last two pictures are quite nice without strings, but shape is not ideal (big edge). Another important thing is that any delay added before the initial unload is completely against the whole ramming sequence principle.

I had similar results with PETG filaments.

Don't take it wrong, your technique is interesting, that is why I wanted to try it in the first place.

[domesticatedviking]

I am encouraged to see there are some test results here. And I am fascinated by your findings regarding the delay being a factor. The thing I don't quite understand is why you would conclude that there is not a benefit to this technique, when clearly the two filaments on the left in your control group (the default group) show unacceptable amounts of stringing, with better candidates in some of the subsequent photos.

A properly working MMU system should be able to have all 5 of those materials with acceptable amounts of stringing, and to me, it seems like your own data show that we have the ability to make that happen, provided we don't adopt an all-or-nothing approach that forces us to choose the same strategy for all filaments that we print with. Skinnydip has always been configurable on a per-filament basis, because there are times when it clearly helps - and there are other times when it doesn't help. If there is a tool that exists that can enable users to print more of the filaments that they already own reliably, it seems like it would be logical to give the users this tool. It also seems like the 3/5 star rating of the MMU2 on Prusa's web shop might relate to the 3/5 filaments printing without strings in the control group. But I might be pressing that point a bit more than necessary.

Anyway, thanks for your time, and I do appreciate what you people do.

[TNDavid]

I have been using Erik,s Skinnydip for some time now, and really like it. I did considerable testing while he was developing it. It has improved the string control immensely. Lowering temps can certainly improve string control, but sometimes at the expense of print quality. Being able to lower temp just for tool change is a great feature. However, my thought ( I actually suggested the approach to Erik) is that lowering the temp before pulling the filament out, then having it go back to print temp before the "Dip" is somewhat counter productive, as it increases print time considerably, and since the melt zone is back to print temp during the dipping process may not be ideal. I would suggest that the filament be pulled into the cooling zone, then the temp lowered during the cooling moves (no time lost), the dipping performed to melt off the string at the temp that produces less stringing, then the temp raised back to printing temp during filament change, again no time lost. This approach would perform Skinnydip and not add any time to the print!

[domesticatedviking]

I haven't forgotten about this theory David. You shall have your experimental version shortly after I gain the capacity to compile my skinnydip-integrated version of PrusaSlicer for Windows. I have spent the last several days trying to get a mac version to compile for Chris but will be taking a run at a Windows build within the week.

[domesticatedviking]

People who want to experiment with the integrated version will find my branch (Currently source code only) here:

https://github.com/domesticatedviking/PrusaSlicer/tree/skinnydip-integrated/

[UlwaziSA]

Thanks Eric,

Will give this a go.

Regards

Mark

On 11 Jun 2019, at 19:21, Erik Bjorgan notifications@github.com wrote:

People who want to experiment with the integrated version will find my branch (Currently source code only) here:

https://github.com/domesticatedviking/PrusaSlicer/tree/skinnydip-integrated/ https://github.com/domesticatedviking/PrusaSlicer/tree/skinnydip-integrated/ — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2385?email_source=notifications&email_token=ALPWTPVTZTVIYRINCWY263LPZ7NJNA5CNFSM4HPVZHA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXN4FPY#issuecomment-500941503, or mute the thread https://github.com/notifications/unsubscribe-auth/ALPWTPQR6B6KBNPJ7QAF74LPZ7NJNANCNFSM4HPVZHAQ.

Mark Stemmett BIng. Pr. Eng Pr CPM for Engineering Advice & Services (Pty) Ltd

Tel : 041 581 2421 Fax : 086 683 9899 E-mail : marks@easpe.co.za mailto:ray@easpe.co.za Web
: www.easpe.co.za http://www.easpe.co.za/

[domesticatedviking]

Thanks Eric, Will give this a go. Regards Mark

Just pushed another commit - it now builds with Visual Studio (as well as for linux and mac). Still a few little visual glitches to investigate, some of which may be VM related.

[cosmith71]

I would like to add my thoughts as an end user.

I successfully used an MMU1. I also had a very good experience with the MMU2, up until about the time I upgraded to the MMU2S several weeks ago. I went from days-long prints with only a couple of interventions to a high number jams in the extruder and MMU load failures. I don't know what changed, but I have spent considerable time making adjustments to hardware and settings and doing test prints to determine the cause. Using the stock Prusa profiles, I was getting strings and weird filament-string-blob tips.

I use many different brands of filaments depending on the color I want, availability, and price. This doesn't help things I'm sure. Prusament may be the best, but it's simply not an option in the US. It is extremely cost prohibitive especially considering the waste on the MMU.

Yesterday I loaded up the Skinnydip post-processor. The dip itself didn't seem to help much, but adding a -5 degree temperature change certainly did. I'm now 20 hours in with a few hundred filament changes with not one intervention required. This is the best result I've had in weeks.

I won't pretend to know better than anyone else on why it works. It may well be the dip, the temperature change, the delay, or some combination of the three. I really don't care at this point. The end result, to an end user, is that this is working incredibly well after weeks of frustration with the stock Prusa solution failing miserably.

Something this post-processor is doing is working. The added time is a fair price to pay for high reliability. This current print would have taken days longer given that jams would invariably happen when I was at work or asleep and the machine would sit idle for several hours waiting for me to address the failed load/unload.

Perception is everything to an end user. The technical explanations and tip comparisons are interesting but mean little compared to final results.

So, until Prusa comes up with some sort of definitive answer to my problems that doesn't involve adjusting a dozen or more separate perimeters, I will use Skinnydip and recommend it to others having similar problems. I would encourage Prusa to continue evaluating Skinnydip because something it's doing saved my MMU2 from going in the trash.

--Colin

[domesticatedviking]

Thanks Colin. I hope to have binaries for my fork of PrusaSlicer with skinnydip routines integrated sometime in the next week or two. I'll post links here. I'll likely discontinue further development of the PP script soon after that -- not only is the integrated version much friendlier to use than skinnydip.py, it is also far more predictable and reliable since it isn't searching for patterns in gcode.

I also agree strongly with your assessment on user experience. The only thing more frustrating than having a problem without a way to fix it, is knowing that a fix exists, and not being able to use it. Fortunately, this is open hardware backed by a great company and a fantastic community. My main interest in lobbying Prusa to include this feature in future builds is to save myself the work of maintaining a fork for myself and others who have found this to be a worthwhile tool.

[cosmith71]

You're welcome, Eric. Almost 24 hours and 538 tool changes and not one single jam on a print I could barely get to run for 45 minutes previously. You may have saved my sanity.

[UlwaziSA]

With all the problems there are with the MMU you would think they would jump at the opportunity. Prusa and many fans appears to always to blame the operator and the build quality instead of making a product with so much opportunity better.

When you are done Erik I will certainly also test for you

On 19 Jun 2019, at 21:24, Erik Bjorgan notifications@github.com wrote:

Thanks Colin. I hope to have binaries for my fork of PrusaSlicer with skinnydip routines integrated sometime in the next week or two. I'll post links here. I'll likely discontinue further development of the PP script soon after that -- not only is it much friendlier to use than skinnydip.py, it is also far more predictable and reliable since it isn't searching for patterns in gcode.

I also agree strongly with your assessment on user experience. The only thing more frustrating than having a problem without a way to fix it, is knowing that a fix exists, and not being able to use it. Fortunately, this is open hardware backed by a great company and a fantastic community. My main interest in lobbying Prusa to include this feature in future builds is to save myself the work of maintaining a fork for myself and others who have found this to be a worthwhile tool.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2385?email_source=notifications&email_token=ALPWTPRWCI62M5KHK62LZPLP3KBW7A5CNFSM4HPVZHA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYDA27I#issuecomment-503713149, or mute the thread https://github.com/notifications/unsubscribe-auth/ALPWTPUEDZOL667IVOHJUCTP3KBW7ANCNFSM4HPVZHAQ.

Mark Stemmett BIng. Pr. Eng Pr CPM for Engineering Advice & Services (Pty) Ltd

Tel : 041 581 2421 Fax : 086 683 9899 E-mail : marks@easpe.co.za mailto:ray@easpe.co.za Web
: www.easpe.co.za http://www.easpe.co.za/

[domesticatedviking]

I think I have all the features I'm planning to implement up and running and pushed those this morning. I've managed to get the integrated fork to compile for Linux, Mac, and Windows. Some visual glitches in the windows and mac versions (maybe due to linker issues?) If anyone is wanting to take a run at helping build some binary packages I'd be thankful. https://github.com/domesticatedviking/PrusaSlicer/tree/skinnydip-integrated/

[domesticatedviking]

For those who are eager to preview / test: PrusaSlicer-Skinnydip Edition 0.9 alpha for win64. It would be a good idea to make sure you have saved a backup of any existing PrusaSlicer profile directory before you run this.

[TheMrCaveman]

Will try tonight

[domesticatedviking]

Spent most of the day yesterday trying to get it compiled for Mac, but an issue with one of the dependencies (wxWidgets) being an outdated version is making that more difficult than necessary. It would be really nice to have some automated builds set up, but I've got a lot to learn if I'm going to do this on my own.

[TheMrCaveman]

@bubnikv don't understand why this cannot be integrated in prusaslicer. MMU2 print's take a lot of time anyway. But A lot of mmu2 users have issues and a lot of user interactions that need to happen before a print can be finished. MMU2 tip settings are a pain in the ass for beginners. Skinnydip makes all those issues a whole lot easier for a lot of users. And that a print takes a few minutes longer but finishes in 1 go is a big experience upgrade. Please look into this. Just as an example a 3:30 mmu2s print takes 3:33 minutes with skinnydip enabled. That 3 minutes is means absolutly nothing.

[K1T00]

I am using the MMU2 for about 8 months now and I want to report too that lowering temperature during ramming helped me a lot. There is a python script from a Prusa community member which does that. After I started using it my success rate went from below 50% to almost 100%.

And I have a question regarding Prusa comments about lowering temperature during ramming: The standard PrusaSlicer 2.0 temperature setting for Prusament PLA is 215°C. The standard PrusaSlicer 2.0 temperature setting for Prusament PLA MMU2 is 205°C. Why is the MMU2 temperature setting made by Prusa lower on the MMU2 version?

@domesticatedviking thank you for your amazing work. Have you also posted this in the Prusa forum? I am sure a lot of people will appreciate it.

[TNDavid]

I am trying to test my theory that lowering the temperature for the dip cycle works as good as lowering it for the retraction, without adding so much time to the print. I want to lower the temp during the cooling moves, and bring it back up during the filament change. I have manually modified a simple one layer two filament skinnydip file to move the temp changes, but have a problem in that the temp change back to printing temp for the first filament does not happen when I want it to. I have the temp change M104 230 command after the skinnydip moves, but it changes during the cooling moves instead. Can someone look at the commented gcode file attached and let me know why the temp change happens long before I want it to? The second filament works correctly, but I am not changing the temp back to 230 on that one, just ending the print. Fast Bjorgan Slicer Test.txt

I have a M109 215 command just before the skinnydip to insure the temp has reached the lower temp, but for some reason it seems that as soon as that temp is reached the temp immediately goes back to 230, before the skinnydip section.

[domesticatedviking]

I'm guessing this sequencing issue is due to the way the gcode is being parsed and planned by the firmware. The firmware doesn't handle asynchronous gcode commands all that well.

[domesticatedviking]

@domesticatedviking thank you for your amazing work. Have you also posted this in the Prusa forum? I am sure a lot of people will appreciate it.

I'm glad you've had some success with it. I haven't made much use of the official Prusa Forum as the Prusa Community Forum on FB keeps me pretty busy. I'm still holding on to the dream that something like this feature will find its way into the main branch.

[TNDavid]

I have been doing a lot of testing over the past couple weeks to evaluate my theory that reducing the temperature only for the dip cycle works just as well as reducing it for the filament retraction, without adding any or at least minimal time to the print. My setup is a MK3 with MMU2. Testing done with PETG, 240 deg print temp, 225 deg dip temp. It is working very well.

The two main problems for MMU2 users are filament strings, and increasing tip diameters over time as the PTFE tube enlarges. I developed a Torlon Tube insert to get consistent tip diameters over time, https://www.facebook.com/groups/prusacommunity/permalink/931436870530379/

I am using Skinnydip for string reduction, but as Skinnydip stands currently if one uses the temperature reduction considerable time is added to the print cycle, far too much for a print with a high number of filament changes.

I first tried dipping a shorter distance than the initial retraction, but that did not have the effect I originally imagined.

I then added the temperature reduction for the dip cycle by modifying a G-code file for a single layer, five filament print. The modified file lowers the temperature during the cooling cycle, with a wait at end of cooling to insure temp has reached the lowered setting, so depending on the cooling time and time to reduce the temperature this may or may not add any time to the filament change. I am using a silicone sock on my hot end, so temp reduction takes longer than one without the sock, but with my 15mm cooling tube length at 1mm/sec so it is very close to the same time, so little to no time added. The temp return to printing temp takes place during the filament change, so no added time.

The greatest impact on string removal turned out to be the pause time at the bottom of the dip! I first had no pause, but that left short wrinkled strings, no time to melt them off. I then tried 200 msec, but that reproduced 4-8mm long strings, time was long enough to remelt the tip end. 100 msec improved it, 50 msec seemed to be the best.

Like Erik, I am hoping that Skinnydip can be added to Prusa Slicer as an OPTION for users, with settings for dip temperature, dip length, and dip pause time. Skinnydip WORKS, but the time addition for temp change as it currently exists is far too great for a print with a high number of filament changes. This modified method works just as well, with little to no time addition.

I am attaching my single layer five filament test G-code text file, hoping that others will look it over and comment, or even better test it to make further modifications or suggestions to further improve Skinnydip to make it viable to add to Prusa Slicer for a fast option for string removal.

Fast Skinnydip Single Layer-5 Filament.txt

[bubnikv]

It is up to @akukan and @rtyr to give a green light for integration of such a feature. @akukan is the original designer of the MMU / MMU2, @rtyr maintains our print profiles.

[tsamisa]

@domesticatedviking . Thanks for the prebuilt version. One issue i encountered though is that when i save a file to 3mf i cannot open it again. Does this happened to anyone else too? Basically any attempt to open a 3mf file fails. Even the ones that where successful with original prusaslicer

[cosmith71]

Can Skinnydip be inserted with the new tool change custom g-code section in PS 2.1.0?

[rmilyard]

@domesticatedviking

I just downloaded your newest FAST version. Not sure what adds. So I am needing some help. I have MK3S+MMU2S with new Bondtech Mosquito extruder. I have been having hard time printing multi color. Normally after first pass of colors the load fails. The tips are little big and some string which I am guessing is the issue. Looking for any guidance as for settings to help try get pass this. Right now trying print with PLA.

[domesticatedviking]

I thought some you would be interested in the latest version of my mad science experiment. The latest version incorporates David Shealey's long requested Fast mode! #2729 Much credit to https://github.com/antimix/ for the 2.1 integration.

You can find 2.1 with fast mode and future builds here until such a time as my gentle persuasion causes someone who knows what they are doing to pick up this tool. (Or a plugin manager to be released. hint! hint!) As always, treat this as experimental and use at your own risk.

[domesticatedviking]

I just downloaded your newest FAST version. Not sure what adds. So I am needing some help. I have MK3S+MMU2S with new Bondtech Mosquito extruder. I have been having hard time printing multi color. Normally after first pass of colors the load fails. The tips are little big and some string which I am guessing is the issue. Looking for any guidance as for settings to help try get pass this. Right now trying print with PLA.

I have no experience using this software with your extruder, nor am I aware of anyone else who has used it, so I'm not sure what advice to give you. This is one of the downsides of customizing hardware -- it makes it a lot harder to support properly (I'm sure the Prusa guys reading this are nodding like crazy here). If you figure anything out, send me a note and I'll incorporate it into the docs. Probably.

[domesticatedviking]

Awesome news for Skinnydip fans: Supermerill has picked up the routines for his fork of Slic3r/PrusaSlicer (Slic3r++). Lots of goodies in his build in addition to Skinnydip - surface ironing, line & sawtooth infill, just to name a few. Make sure to thank him for his great work!

Not sure whether his current binaries will have the routines yet. In the meantime you can pick up one of my builds for Windows, OSX, or Linux here.

[domesticatedviking]

SuperMerill has released his first build with skinnydip integrated. Very happy to have his support on this - I have a lot of respect for his contributions to the community. (Frankly, he's way better at this than I am.)

[RolfHodl]

So here is still my problem - mk3s + mmu2s with petg is a strining mess - what is the actual solution now with prusaslicer 2.1.1 . I never could finish a multicolour print but every single color works perfekt.

[BWBNexus]

Multi Color PETG prints have the temps dropped to 230 vs single color prints at 250. Just saved the defaults PRUSAMENT MMU2 PETG profile to first layer 240 and other layers 250. My Multi color PETG prints work great now

[0lympu5]

has anybody got this working with prusa slicer? or can help me with an issue concerning ramming distance

[TNDavid]

has anybody got this working with prusa slicer? or can help me with an issue concerning ramming distance

It has been incorporated into Slic3r++, based on Prusaslicer, but has a reported problem with the temp changes not working correctly. The interface in Slic3r++ is really nice, but this bug has to be addressed to be useful.

[0lympu5]

@TNDavid atm i cannot find a way to allow for a different extruder design than the prusa one. I tried increasing the cooling tube position so it retracts more to clear the gears but then at the last mine it loads by around the amount i increased it.

[ANTALIFE]

@josefprusa even if you guys don't fully implement skinny dip, can we at least get an option to change temperature during unload?

[bobarby2002]

So I am new to all this 3D printing. I have a Prusa MK3S assembled 6 weeks ago. MMU assembled 2 weeks ago. took 2 weeks to get MMU to work with PETG/PVA with no user intervention. Very tempted at times to chuck the machine. Ultimately in the printer settings changes made to: Cooling tube postion 50 tube length 45 parking position 85 extra loading at -25

this was what made it all work. (some tweaking on the filament and print but this was key.

All this is to ultimately use 0.25mm nozzle. Nozzle change done yesterday and that when the problems started. settings changed on machine to 0.25 and prusa slicer config made for 0.25 MMU (doesnt exist in the config). Couldnt print anything. tips were disasstrously elongated and stringy. clogging. user intervention every few minutes.

I googled frantically and came across skinnydip. did the job! printing now with just skinnydip enabled. still a little stringy but works like a charm. fingers crossed I can finish this.

Bear in mind the PETG/PVA is not ideal and I had much less issues with PLA/PVA. Ultimately I need to print food safe items and biocompatible filaments. so all this is to get ready for those.

Couldnt get it to work with Prusaslicer so I ended up downlaoding the Slic3r version with skinnydip.

Wanted to thank @domesticatedviking

[ALittleSlow]

I had been using @antimix's Dribbling version of PrusaSlicer to good effect. Then I blindly installed stock PrusaSlicer 2.3 only to discover days later that the profiles in 2.3 are not backwards compatible to 2.2, leaving me a bit of a mess. :(.

Seeing that Antimix hadn't yet updated his code to 2.3, I took another route. I'm happy to report that I've got a kind of skinnydipping/dribbling working in stock PrusaSlicer 2.3.0 using just a PrusaSlicer macro. It's a bit rudimentary, but so far my results are as good as what I got with Antimix's version. My solution is to save my "dribbling" temperature in the filament_notes (e.g. DRIBBLE_TEMPERATURE_190) and to put the below in Printer Settings->Custom G-Code->Tool Change G-code:

; Simulate "Dribbling"
{if (layer_num>=0)}
{if (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_190.*/)}M104 S190 ; cool to the dribble temperature
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_200.*/)}M104 S200 ; cool to the dribble temperature
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_210.*/)}M104 S210 ; cool to the dribble temperature
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_220.*/)}M104 S220 ; cool to the dribble temperature
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_230.*/)}M104 S230 ; cool to the dribble temperature
{endif}
M106 S255 ; cool the nozzle
G1 E35 ; undo the E-35 from the WIPE
{if (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_190.*/)}M109 S190 ; cool to the dribble temperature
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_200.*/)}M109 S200 
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_210.*/)}M109 S210 
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_220.*/)}M109 S220 
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_230.*/)}M109 S230 
{endif}
G1 E-35 ; and warm pull
M106 S0 ; turn off the fan to speed the warmup
M109 S{if (layer_num==0)}{first_layer_temperature[next_extruder]-15}{else}{temperature[next_extruder]-15}{endif} ; help ensure the nozzle is warm enough before loading
M104 S{if (layer_num==0)}{first_layer_temperature[next_extruder]}{else}{temperature[next_extruder]}{endif}
; T[next_extruder] ; if we specify a tool change here, the slicer will respect it and not insert its own T code. This means you can write your own *after* tool change code
; After tool change code
{endif}

A couple problems I'd like to solve still

• Wipe while waiting for the dribbling temperature so we don't make a blob. So far that's not been an issue.
• Prevent WIPE from setting next extruder temperature, since if it's higher than the current extruder temperature it will take longer to cool it down
• Extract and print the actual dribbling temperature from the filament_notes so I can get rid of the ungainly if-elsif-endif structure

[ANTALIFE]

I had been using @antimix's Dribbling version of PrusaSlicer to good effect. Then I blindly installed stock PrusaSlicer 2.3 only to discover days later that the profiles in 2.3 are not backwards compatible to 2.2, leaving me a bit of a mess. :(.

Seeing that Antimix hadn't yet updated his code to 2.3, I took another route. I'm happy to report that I've got a kind of skinnydipping/dribbling working in stock PrusaSlicer 2.3.0 using just a PrusaSlicer macro. It's a bit rudimentary, but so far my results are as good as what I got with Antimix's version. My solution is to save my "dribbling" temperature in the filament_notes (e.g. DRIBBLE_TEMPERATURE_190) and to put the below in Printer Settings->Custom G-Code->Tool Change G-code:

; Simulate "Dribbling"
{if (layer_num>=0)}
{if (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_190.*/)}M104 S190 ; cool to the dribble temperature
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_200.*/)}M104 S200 ; cool to the dribble temperature
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_210.*/)}M104 S210 ; cool to the dribble temperature
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_220.*/)}M104 S220 ; cool to the dribble temperature
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_230.*/)}M104 S230 ; cool to the dribble temperature
{endif}
M106 S255 ; cool the nozzle
G1 E35 ; undo the E-35 from the WIPE
{if (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_190.*/)}M109 S190 ; cool to the dribble temperature
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_200.*/)}M109 S200 
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_210.*/)}M109 S210 
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_220.*/)}M109 S220 
{elsif (filament_notes[current_extruder]=~/.*DRIBBLE_TEMPERATURE_230.*/)}M109 S230 
{endif}
G1 E-35 ; and warm pull
M106 S0 ; turn off the fan to speed the warmup
M109 S{if (layer_num==0)}{first_layer_temperature[next_extruder]-15}{else}{temperature[next_extruder]-15}{endif} ; help ensure the nozzle is warm enough before loading
M104 S{if (layer_num==0)}{first_layer_temperature[next_extruder]}{else}{temperature[next_extruder]}{endif}
; T[next_extruder] ; if we specify a tool change here, the slicer will respect it and not insert its own T code. This means you can write your own *after* tool change code
; After tool change code
{endif}

A couple problems I'd like to solve still

• Wipe while waiting for the dribbling temperature so we don't make a blob. So far that's not been an issue.
• Prevent WIPE from setting next extruder temperature, since if it's higher than the current extruder temperature it will take longer to cool it down
• Extract and print the actual dribbling temperature from the filament_notes so I can get rid of the ungainly if-elsif-endif structure

Kayl built 2.3.0 here https://forum.prusaprinters.org/forum/original-prusa-i3-mmu2s-mmu2-general-discussion-announcements-and-releases/prusaslicer-dribbling-version-for-mmu2-updated-to-latest-prusaslicer-2-1-0-rc/paged/3/

[Alfiegerner]

Just wanted to add another voice that this is a very useful feature, I wasn't able to solve some of my stringing issues with the options available in PrusaSlicer as is, but using skinny dip in SuperSlicer I was.

[notching]

Yep - switched to superslicer because of this not being integrated into prusaslicer.

[jwhite]

How is this still not in PrusaSlicer? I'm here because I want arachne... but I'll have to go back to superslicer for my muti-material prints.

[Imburr]

Would love to see this added.

[AustinTylerDean]

I finally get to the part of the ERCF installation where Skinny Dipping is discussed... and it's not available in PrusaSlicer.

I'm totally proud of how much I learned in the last 9 months with a Voron and ERCF but... man that Bambu Labs X1C is looking like it was the smarter move. I mean, I spent the same! And all I'm doing is exactly what the PRC funded a bunch of DJI engineers to do....

:|