Tool change custom Gcode

Currently there is just one custom Gcode block for all tool changes but its seems that it would be very useful to be able to specify custom Gcode when it changes to or from a specific extruder.

As you know not all extruders are equal.

For instance, lets say that when I change away from one tool head I need to wipe the head on one side of the bot but when I change away from the other toolhead I wipe the head on the other side (i.e., each head has a wiper attached to the X axis it is closest to).

The only way I can see how this can be done properly (i.e., not just hacking the firmware) is to be able to
a) have separate tool specific change to and change from custom G-code sections, or
b) define conditional sections in a single custom Gcode block.

The latter solution sounds better as it keeps the UI simple for people who don't need this sophistication..

[[change_from_extruder0]]
G1 X0 F12000 ; wipe left
G1 X[previous_X]
[[/change_from_extruder0]]
[[change_from_extruder1]]
G1 X310 F12000 ;
G1 X[previous_X]
[[/change_from_extruder1]]

[Previous X is the previous X position before it entered the custom G code section (you would probably need previous_Y, previous_Z & and previous_E).]

Thoughts? (you would probably want to do a retraction and lift before moving but wanted to keep the example simple)

Edited 3 time(s). Last edit at 02/19/2013 06:58AM by buildrob.

buildrob Wrote:
-------------------------------------------------------
> Currently there is just one custom Gcode block for
> all tool changes but its seems that it would be
> very useful to be able to specify custom Gcode
> when it changes to or from a specific extruder.
>
> As you know not all extruders are equal.
>
> For instance, lets say that when I change away
> from one tool head I need to wipe the head on one
> side of the bot but when I change away from the
> other toolhead I wipe the head on the other side
> (i.e., each head has a wiper attached to the X
> axis it is closest to).
>
> The only way I can see how this can be done
> properly (i.e., not just hacking the firmware) is
> to be able to
> a) have separate tool specific change to and
> change from custom G-code sections, or
> b) define conditional sections in a single custom
> Gcode block.
>
> The latter solution sounds better as it keeps the
> UI simple for people who don't need this
> sophistication..
>
> []
> G1 X0 F12000 ; wipe left
> G1 X
> []
> []
> G1 X310 F12000 ;
> G1 X
> []
>
>
>
> Thoughts? (you would probably want to do a
> retraction and lift before moving but wanted to
> keep the example simple)

Probably a more general mechanism would be simply to implement conditional custom G-code sections using a == or != test.

For instance, the previous example could be more generally implemented with

[[previous_extruder==0]] 
G1 X0 F12000 ; wipe left 
G1 X[previous_X] 
[[/previous_extruder==0]] 
[[previous_extruder==1]] 
G1 X310 F12000 ; 
G1 X[previous_X] ; wipe right
[[/previous_extruder==1]]

rather than specific purpose tags.

Edited 1 time(s). Last edit at 02/20/2013 05:04AM by buildrob.

Hello,

do you know if this type of code works ?
Because "previous_extruder" and "next_extruder" is implemented but if i'm right you cannot use conditionnal code (If ... Then -> End If) in the G-code like in CNC ?
I'm interesed by this fonction but for the moment I don't kow how to use for my own reprap ...

The best way will be have a custom G-code for engaged for each tool separatly in slic3r.

Edited 1 time(s). Last edit at 05/17/2014 07:41AM by Steph ane.

Hi Steph ane,

This was a suggestion I had to solve the problem of wiping to the left and right with dual extruders - unfortunately there wasn't any interest in it.

Cheers,

Rob.

This would be necessary in case of a 3+ extruder setup, has anyone used or heard of conditional G-code in 3D printers which responds to a specific tool switch?

---

Canadian

I Haven't, that's way I have subscribed to having the Slicer generate tool change fences and towers. The other issue is When there are no other tools select till the end of the print. The current implementations (I have seen) continues to switch tool every layer. Evian though you are using the same tool. Agene this would be done in a Post operation to optimize this. The slicer people Seam to think this good enough. Yet I fight this issues overtime I do a Malty tool print. Strings everywhere from the tool change, Support material getting mixed with plastic the part is mad of. I guess what the customer needs dos not mater any more. Cura allows you to build Post process Plugins, but no facility to test them other then to run a print (Debugger shell). Also Cura tower will not allow you to put a Fence between the Prime tower and the Tool path. Slic3r is a Little beater, but there extruder calk's for flow control in the Slicer are abominable. and parts don't come out to size they are supposed to be. This guys work hard and I am not complaining so much for them but the pay software is twice as bade. Evian on industrial systems. I guys the next step for the slicer industry is for people to start developing tools for the plugins and post processers for the GCODE. This way the state of the slicers wont mater as much. Any way, My rants and raves

I suppose a clunky workaround would be to wipe both nozzles in succession after every tool change.

Dave