Notifications
Clear all

acting as my own MMU  

Page 2 / 2
  RSS
Kenour
(@kenour)
Estimable Member
RE: acting as my own MMU

Worked for me last week, but with slicer 2.1 it's being a bit... weird.

https://forum.prusaprinters.org/forum/prusaslicer/multiple-colours-for-a-sign-with-2-layer-text-2-different-materials-and-2-filament-changes/#post-161612

If you could see your way to updating the method that would be great 😀 I had to disable the wipe tower and tweak some other things to have it work like it used to, but the first thing it does now is spits the filament as soon as the purge line is done 🤣 Which isn't helpful...

It also seems that the 'Clip multi-part objects' seems to be broken? I'll keep playing, managed to get printed what I needed to, albeit rather painfully. I might put 2.0 on another machine for now until either the guide is updated or the issues resolved... Or I figure out how to do it myself and why it's now behaving so super weird 😋 

Posted : 22/09/2019 11:16 am
Kenour
(@kenour)
Estimable Member
RE: acting as my own MMU

Clip multipart works, my bad... I just have to import them separately. Not as a multipart object, or it tried to print in the same space twice.

Posted : 22/09/2019 12:05 pm
Kenour
(@kenour)
Estimable Member
RE: acting as my own MMU

I take that back... I don't know why it seems to sometimes work and sometimes not.

I'm doing an update of a bin logo I made, and it seems to be trying to print the black and silver in the same area.

Notice the black doesn't have perimeters. Probably something simple, but not seeing it.

 

Posted : 22/09/2019 10:06 pm
Kenour
(@kenour)
Estimable Member
RE: acting as my own MMU

Is there any chance of an update? I've noticed that it spits the filament as soon as it finishes the initial purge. Not sure what's causing it, but happening with the new version of the slicer. I've found this process really useful for sign making and product branding. Cheers 😀

Posted : 31/10/2019 2:33 am
NickRno77
(@nickrno77)
Trusted Member
RE: acting as my own MMU

I'm having great success with multi colour printing with no mmu, one problem I have come across.... after filament change the extruder moves over a previous colour and drop a spot of filament. Sort of primes the nozzle, this is not needed as I've set prusaslicer print each colour onto the skirt. This is a problem if I have a white layer then a dark colour is printed onto that.

Posted : 14/09/2020 11:03 pm
roy-2
(@roy-2)
New Member
RE: acting as my own MMU

Thanks for this

Just testing this with my Ender 3, and it works well, but doesn't tell me which colour to choose when asking for more filament. I found that in the gcode, though, like

M600
T3

With T3 mapping to the colour set in the slicer (SuperSlicer, actually, but hell, it's about the same). Is this parsed correctly in newer firmwares or do I need to add somethingm more than just M600 in the custom gcode setup?

Posted : 18/11/2020 5:05 pm
Diem
 Diem
(@diem)
Noble Member
RE: acting as my own MMU

Here are two perl scripts that might help.  The first one has been published before in thread: https://forum.prusaprinters.org/forum/prusaslicer/manual-multicolor/ - which is well worth reviewing for workarounds to some of the issues raised here.

 

If you already have the correct filament loaded and don't need the first filament change run this to edit the gcode file:

#!/usr/bin/perl
# Copy (gcode) file except comment out first line including 'M600' - toolchange.
use strict;
my $done=0;
while(<>){
if($done){
print $_;
} else {
if(/M600/){
print ';',$_;
$done++;
} else {
print $_;
}
}
}

Copy it as detool.pl (the filament changes are implemented as tool changes,) make it executable and run it like this:

#    detool.pl /path_to/slicer.gcode > /path_to/printer.gcode

The second script reads the gcode file and reports the sequence of filament changes.  Use this to keep track of which filament to load next.

#!/usr/bin/perl
# Count 'M600' changes and report 'Tn' extruder selections
use strict;
my $count=0;

print"\nFilament changes; expressed as extruder selection, "
."in gcode created for manual multicolour printing.\n\n";

while(<>){
if(/^M600/){
print 'Change -> ';
$count++;
}
if(/^T(\d)/){
print "Extruder ".($1+1)."\n";
}
}
unless($count){
print "No 'M600' filament changes detected.\n";
}else{
print "$count 'M600' filament changes.\n";
}

Copy it as changes.pl and make it executable.

Run it like this:

#    changes.pl /path_to/slicer.gcode

Or if you have a complex print and want a file to refer to try:

#    changes.pl /path_to/slicer.gcode > filamentchanges.txt

Which lists the exchanges by extruder number thus:

Extruder 1
Change -> Extruder 2
Change -> Extruder 1

You just have to keep track of which extruder refers to which filament.

 

Both scripts should work as-is on almost all Linux distros including Raspberry Pi, on Macs and on a great many other systems; if you have a very unusual setup you might need to change the first line to point to your Perl installation. If you use Windows you will have to install Perl from somewhere and maybe pay for it.

Posted : 18/11/2020 6:47 pm
roy-2
(@roy-2)
New Member
RE: acting as my own MMU

I'm on a mac, using a pi to feed the printer, and I speak perl pretty fluently, so no issues here. Still, what I wondered about, wasn't how to read or change this, but if there's a way to somehow transfer the filament change to the console/LCD screen, saying "I want colour three" or something, with some GCODE. The code at https://github.com/rkarlsba/ymse/blob/master/trede/colours-to-lcd.pl is an attempt to do this, but it seems the M117 is overridden by the next M600 so you won't see much on the display if it even shows up there. It could work with a "press to continue" to make it wait until M600. Anyway - it'd be nice to have the slicer do this job instead of post-processing everything, even though this doesn't happen too often…

Posted : 18/11/2020 10:35 pm
Diem
 Diem
(@diem)
Noble Member
RE: acting as my own MMU

@roy-2

This method works within the features of the official firmware; to report the filament needed to the LCD screen would require modifications to the firmware.  There was an experimental fork which did this, for context read this thread:

https://forum.prusaprinters.org/forum/original-prusa-i3-mk3s-mk3-user-mods-octoprint-enclosures-nozzles-.../simple-way-to-print-in-real-multi-color-without-mmu-or-layer-height-based-changes/paged/1/

But if you're using a Pi you might try using octoprint to monitor tool change events and trigger an Action Command Prompt.

Posted : 19/11/2020 11:04 am
Felenari
(@felenari)
Eminent Member
Going to try this.

I'm going to have to try this since I blew my whole budget on the printer this year. 😛

Not old till you hit triple digits...
-Güber McSanchez....
Posted : 07/10/2021 5:33 pm
Page 2 / 2
Share: