Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Feature request: [active_extruder] variable in layer change G-code #2866
It would be extremely useful to have a [current_extruder] or [active_extruder] variable in the custom layer change gcode field.
This variable is the missing puzzlepiece required for switching extruders within custom layer change procedures (such as cleaning nozzle tips on a brush or adding custom wipe/prime towers), because one would have to switch back to the currently active extruder afterwards by adding a T[active_extruder].
Anyway, I would be glad to hear some comments on this. Of course one can add all kinds of extras using post processing scripts, but I just think this would be an extremely useful variable that would open up many useful possibilities and an easy way to address scenarios where the current ooze prevention feature might not bring the desired results.
For illustration, I need this for improving my wipe tower script, which prints one hollow wipe tower for each extruder on each layer change, but there are probably many other cases, where this might come in handy, such as custom wiping hardware that needs to be approached by each extruder on every layer change or so. However, if I had the [active_extruder] variable in the layer change, my towers would look like this:
but since the variable is not there, I can only print the wipe towers with the active extruder, which looks like this:
So this is already nice, since the printer can wipe E0 on the wipe tower for E0, but the wipe tower might be of a different filament color, so there might be a little smear. And the extruder might have been out of operation for a long time, so one has to purge way more material on tool change, which can clog the tower.
So what this does is, on every layer change, it prints a pre-generated hollow wipe tower for every extruder. Then, on every tool change, it lets each extruder travel to the center of it's own hollow wipe tower, extrudes a little filament, travels out of the wipe tower to wipe away the string, and goes back to normal operation. That works, because the corresponding tower can be selected just by travelling to the first tower, then switching to relative positioning and using "G1 X[next_extruder]0" if the towers are spaced 10 mm center-to-center.
Here's the "After layer change G-code":
And this ist the "Tool change G-code":
changed the title from
[active_extruder] variable in layer change G-code
Feature request: [active_extruder] variable in layer change G-code
May 30, 2015
added a commit
May 31, 2015
my approach is printing one wipe tower for each extruder, which works for as many extruders as you like. This method ensures that an extruder is always wiped on a wipe tower of its own material, which is important for multi material prints with different print temps and contrasting colors. You just have to add a G-code snippet for printing all the towers on layer change, then add the G-Code snippet for wiping the next_extruder in the custom tool change G-Code.
But I think it does not make sense to print the wipe tower on tool change and on layer change, since the wipe tower has to be printed on each layer change, so that we can use it for the actual wiping move if a tool change occurs in a layer, and there might be layers where no tool change occurs, too.
In most reasonable scenarios, there's maximum 1 tool change per extruder per layer. Therefore it would, however make a lot of sense to look ahead in the G-Code, and if a tool change is about to happen in a particular layer, skip the printing of the wipe tower on that layer change and move it to that tool change instead. That way, one could save away the wiping moves entirely, which would save a little printing time.
However, it would be tedious to beef up custom G-Code fields for those kind of tasks (would require conditional statements like [if]/[else] and a bunch of new vars like [does_next_layer_contain_tool_change]), better use a post processing script. I also went on to generating my wiping towers with a little Perl script meanwhile.
added a commit
Jun 10, 2015
just wanted to share my scenario and how to have an IF statement would help and simplify using g-code.
So in the Tool Change G-code I would like to have an IF statement like this:
Does it make sense?
As far as I understand the matter, mapping tool changes to servo angles is more a "firmware-thing". So you might want to perform those actions in firmware, having the Tx G-code trigger the servo motion accordingly.
However, until Alessandro delivers a turing complete Custom G-code environment, which is bound to happen sooner or later, you could solve this quick and dirty using a Perl post processor script like this: