acting as my own MMU  

RE: acting as my own MMU

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

https://forum.prusa3d.com/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 😋 

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.

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.

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 😀

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.

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?

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.prusa3d.com/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.

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…

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.prusa3d.com/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.

Going to try this.

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

RE: acting as my own MMU

go to the Custon Gcode and choose Tool change G-code and insert M600

I am currently trying this with a Mini+ and this particular line was the only thing I've been missing.

I will also try rotating the object so that the letters are printed on the steel sheet instead of at the top.

I still got one question though:

How can I add an intro line / purge line after every filament change? There seems to be no option for that and I'm not sure about the exact g-code for printing the line atop the old ones or just next to them (I've got enough space there).

A wipe tower seems to be absolute overkill and it's apparently buggy in Prusa Slicer 2.4.2 since no matter how small I set the width and the (idiotically placed setting for the) minimum wipe area, the wipe tower is always a super long object and I cannot reduce its size.

How can I add an intro line / purge line after every filament change?

You don't.  See @joantabb's first post on this thread :-

  https://forum.prusa3d.com/forum/prusaslicer/manual-multicolor/

Cheerio,

RE:

Seriously? I have read the post of course and I'm doing it exactly as described since it's the obvious workaround to the problem. However, the problem is still a problem and grabbing the "wormcast" each time with tweezers or something is very janky, which is specifically why I'm asking...

Your answer sounds a bit like "just shut up and do it manually". If you don't know, maybe just don't answer. Theoretically it is possible to add the intro line gcode accordingly and I'm pretty sure that somebody has already done this before and could share the knowledge here.

; intro line
G1 X170 F1000
G1 Z0.2 F720
G1 X110 E8 F900
G1 X40 E10 F700
G92 E0

It's easy to add a purge line - but fraught with difficulty in avoiding a print crash especially as the print grows.

Each time would require the print head to find a free space for the purge line and move to layer 0 without colliding with the print OR a previous purge line ( unless you stack the purge lines - that's a purge block ... ) and then return to position for the next part of the print also without collisions.  This quickly becomes a geometric nightmare.

Cheerio,

RE: acting as my own MMU

I understand the difficulty of avoiding collisions, but most signs or badges etc. where this entire process is applicable will only be flat objects, most with a height of less than 1 cm which is why printing that intro line repeatedly on the absolute border of the regular print area should be possible.

I would say that it's also possible to remove the purge line easily enough while something is being printed so that adding the same gcode again should also work. But yes, a purge block would be awesome to try out.

Alas, in my tests all results with PVB involved look mediocre, especially when rotated by 180°, and printing (relatively small) letters with just two more layers on top look best despite the sign not being a flat surface then. It's probably different with non-transparent material.

adding the same gcode again should also work.

It should, but sooner or later the user will forget and we're troubleshooting crashes.

But yes, a purge block would be awesome to try out.

Just enable it ... or rather, don't disable it.

Cheerio,

RE: acting as my own MMU

I haven't tried it, but You could try enabling a draft shield. it would probably knock your worm-cast off the nozzle on the way back to the print.
regards Joan

RE: acting as my own MMU

That's an excellent suggestion, thank you!

RE: acting as my own MMU

Thanks for this thread, and to @Joan Tabb for her instructions on how to pull this off w/o the MMU which is where I am at right now.

Don't really want to invest in the MMU2 as I have a reservation in for the XL but I know that is a way off so just have to deal with it as best I can.

RE: acting as my own MMU

Yeah this is annoying, I've found it's the M600 command itself, that seems goes back to the position where it was called.

I only do multicolour on the first 2 layers; lay down the first layer with the lettering outlines, colour change, do two layers of the text, change colour, carry on.

I use a skirt for purge/prime.

The issues I still have are the M600 directly after the purge line, I don't understand why this is here?

After M600 it returns to the same position and does a little poop, and if it's small lettering, it will sometimes catch it and lift it off, and/or leave a smudge.

What I've done to fix it is;

Comment out the first M600, sorted.

For the first layer, moved the colour change so it happens in the skirt.

Annoying little annoyances, but this worked for me.

So this section;

; Filament-specific end gcode
M600
T1
M104 S230 ; set temperature
M900 K0.08 ; Filament gcode LA 1.5
M900 K45 ; Filament gcode LA 1.0

G1 E-1.5
G1 X75.728 Y55.958 F10800
G1 Z.2 F720
G1 E1.5 F2100
M204 S800
;TYPE:Skirt/Brim

Became this (note: I had to put my own retraction hop in <G1 Z.4 F720> otherwise it would have dragged across the lettering);

; Filament-specific end gcode
G1 E-1.5
G1 Z.4 F720
G1 X75.728 Y55.958 F10800
M600
T1
M104 S230 ; set temperature
M900 K0.08 ; Filament gcode LA 1.5
M900 K45 ; Filament gcode LA 1.0
G1 Z.2 F720
G1 E1.5 F2100
M204 S800
;TYPE:Skirt/Brim

Hope this helps, if there's a better way I would love to know. It really seems this is how it should operate, but ahh well. Obviously not an expert, but can tinker enough to get a result.