Help with tool change macro please

[deckingman]

Hi Tony,

Thanks for that. I wasn't aware that Prusa had a smart priming tower thingy - I'll take a gander.

For info, I got impatient and tried that which I wrote in my first post. When I started a print, all I got was a never ending series of messages "Push(): stack overflow", when it got to the point where it changed tool.

Thanks for the info - I'll try and do it properly.

Ian

[dc42]

I think the stack overflow was caused by having a T command in a tool change file, which caused the file to be invoked recursively.

I recommend that you balance each G10 command with exactly one G11 command.

[deckingman]

Thanks guys.

I'm making progress but not quite there. I have

tfree(n)
G10;retract

tpre(n)
G90 ; set absolute positioning …............(just to be on the safe side)
G1 X300 Y300 F21000 ;move to near the far right hand corner of the bed at 350mm/sec
G1 E20.0000 F600 ; extrude 20mm of filament at 10mm/sec
G10 ; retract to stop any more oozing out.
G1 R1 F21000; move back from whence we came

and tpost(n)
G11; unretract

It's not extruding the 20mm of filament (or maybe it is but during the fast move to the far right corner). I guess my G1 E20 F600 isn't the right way to go about it.

What I'm trying to achieve is to retract (to stop oozing), then move away without extruding anything, then dump 20 mm (need to refine the exact amount) of filament in the corner, then retract slightly to stop it oozing further, then move back to whence we started, unretract and carry on.

[T3P3Tony]

I think you should put everything you want to happen with a tool after its selected and before it starts printing in the tpostN.g so that would include the purge. In your usecase I don't see a requirement for tpre.g at all.

Also should you not have a G11 before you start to purge so that all the filaments are back in their original positions before purging with one (to prevent backflow)? Another thing to check is that you are using relative extruder commands (M83) rather than absolute. I would always add a M83 before any extruder commands in the tool change gcodes as it makes them safe for slicers which use absolute extruder commands

G1 commands are executed sequentially so the G1 E20.0000 F600 should occur after the G1 E20.0000 F600 has completed.

[deckingman]

Thanks Tony, I'm getting there. So now tfree just has G10 ; retract, tpre is empty and tpost has this:
G90 ; set absolute positioning …..(just to be on the safe side)
M83 ; Set relative extruder.........(just in case)
G1 X300 Y300 F21000 ;move to near the far right hand corner of the bed at 350mm/sec
G11 ; unretract - to cancel out the retract in tfree
G1 E20.0000 F600 ; extrude 20mm of filament at 10mm/sec
G10 ; retract to stop any more oozing out.
G1 R1 F21000; move back from whence we came
G11; unretract

I've created a dummy tool (T90) and used a T90 in my config.g to have this as the first tool selected. I'll put the same T90 command in my start gcode file, followed by an M109. This is to prevent running foul of errors associated with trying to drive a tool without the heater being up to temperature as will happen when I first select a tool (because it always tries to extrude and the heater is cold).

So, I've tried changing tools from DWC with the machine static and it's working fine. The only thing that doesn't happen is that it doesn't move back from whence it came (G1 R1 F21000;). I'm guessing that's because it only knows where the origin was while it's actively printing and not when the machine is stationary. It's no big deal but is there a way around it?

Cheers
Ian

[T3P3Tony]

I have not tested the R1 functionality of G1.

Glad it's starting to work for you!

[deckingman]

Quick update. The macros are working and doing what I expect. There a couple of things that I have to overcome. I may need to put a bit of Z hop in, mostly because on selecting the first tool the nozzle is at or very close to the bed when it does the first extruder purge. The second thing is that it needs something to physically wipe the nozzle. This isn't easy to do on my machine because the bed is larger than the printable area. That is to say, there is no place where the nozzle isn't over the bed. It needs some thought but methinks this could be a fairly major re-design of the printer. Still, it's showing promise….....

[StephenRC]

One idea would be to make a hole in the bed to install a scraper into.

[T3P3Tony]

This goes back to printing a tower for purging, investigation of that might be quicker than redesigning your printer to allow for a purge bucket within the movement range of your XY axis.

I have not looked at Prusa's smart tower yet but my idea would be to calculate the amount of filament required to purge the layer that needed the most purging, (ie the one where the most tool changes occurred before a Z movement). Then build a tower that had enough volume at 100% infil to absorb that many purges in one layer. All layers with less purges would print at a minimum the perimeter of the tower and as much infil as required to purge that layer. Maybe modify so the first layer was printed at 100% infil even if not required do the tower was firmly anchored on the bed.

This is definitely something that the slicer should be doing because it needs knowledge of the whole print job in advance. Also a good slicer would allow you to place the print tower anywhere on the bed as an object.

Even cleverer slicers should be able to allow you to purge as part of infil but that would require even more development work.

Not that any of this helps you, except for the idea of seeing how Prusa is doing it.

[deckingman]

I could make a hole in the bed - bit difficult though - I have 10mm thick aluminium with 240v silicone heat mat stuck to the underside and semi rigid insulation under that, oh and then 6mm glass on top. Actually, I may be able to slide the entire ting forward enough - dunno - have to investigate.

Tony - the smart tower is a good ides but exactly how it's done seems to be a bit of secret. How do you purge say 3 different colours that are to be printed on the same layer in such a way that each one is printed sequentially after each purge (as is needed with a single nozzle) ?

Purging at layer change is a piece of cake. In fact, if the object is a reasonable size, you don't even need to. You can just set 3 or 4 perimeters and the slicer will always do the inner ones before the outer ones so the inner perimeters effectively act to purge the new filament through. It doesn't matter is they are a bit "streaky" because they get covered up.

Say you have 3 tools (colours) A, B and C. With a mixing nozzle, you start with A and print that part of the layer - change to B move away and purge B - move back and print that part of the same layer - change to C - move away and purge that colour - move back and print that part of the layer using C - change back to A - go to the next layer and start over. If you have tower, you have to print it every layer, whether there is tool change or not. How else could it work if you have say 20 layers before a tool change? How do you cope with 3 colours on the same layer? 3 towers? Prusa talks about "slots" within a tower. Maybe that's 3 towers in one? Dunno…....

Prusa's approach is all done post processing, so it's not native to the slicer. However it's done it's very clever.

I'll have to dig around some more.

Ian

[T3P3Tony]

Ian

My thought process in more detail:

For layers where you have no tool change you just print the perimeter of the tower in whatever tool is selected.

At every tool change, be that during a layer, or on the layer change, you print enough of the tower so that the nozzle is purged, the rest of the tower is not printed. Once per layer, the perimeter is printed before anything else is done.

The size of the tower is determined by the number of tool, changes so if you need 3mm^3 of filament extrusion to purge and the print has 4 tool changes on the most complex layer, then the tower must be large enough to absorb 3x4 = 12mm^3 of filament on this worst case layer, printed in 4 sections one after each tool change.

Experimentation would be required to see if some infill was required, or a double perimeter for any tower dimension to work, especially if you had a situation where the tool changes were not evenly distributed through the print.

It could be optimised significantly for time and filament usage by printing a smaller tower if under the worst case layers there was a big enough gap so that the tower effectively became a purge bucket for these worst case layers.

–--

If I get a chance I will look into how Prusa's post processing script does it,

[deckingman]

Tony,

Yes, I think I see where you are coming from - effectively printing purge "bucket" on the bed, the inside of which is basically a container for whatever filament (s) need to be purged. Hmmmmmmmmm

[T3P3Tony]

Ian

Yes, just optimising to use as little filament for purge bucket printing as required, however as an interim measure you could literally print a bucket that was oversized so you were sure to capture every purge and then just purge into it by printing in 1 separate place for each tool change.

[deckingman]

Quick update. I've commented out the codes that I had in tpfree/post etc and put them into the Custom Gcode - Tool Change section of Slic3r. Did a quick slice and taking a gander at the resultant gcode file, it looks like it'll work. It's much more elegant doing it this way as the commands will only be executed during a print and not at other times when I'm playing around with things. So I don't need the dummy tool in my config.g. Also, the codes are only executed on tool change and not tool selection so it doesn't do this extra purge thing at the start of a print, therefore I won't need the Z hop. Now to figure out the tower thing….....