Variant of Goopyplastic's Tantillus Variant (Ingentis)

@ Jimjimma

I notice on your g+ wall you are using Slic3r because it currently is capable of doing different nozzles for different extrusion types. You could easily do this in Kisslicer or Cura with a simple post processor. I wrote a post processor for them to change the flow rate of each section but it could be modified to insert the tool change command at the same points (perimeter, solid infill, sparse infill, support, loops). You can find my post processor [github.com] and all you would have to do is change the sections that say "set ......".

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

@Sublime

Oh, awesome. That is perfect. I had already started thinking about this as I knew Kiss had such good annotations in it's gcode. I really hate slic3r so it's a good way forward, my only qualm is the apparent lack of developent with Kiss now, last time I looked, the forum was a spam-fest and it appeared that Jonothan had fallen off the map....
Without having a good look at your script, I would also need to apply a translation to the x/y coords for nozzle changes.

Thanks man

Quote
jimjimma
@Sublime

Oh, awesome. That is perfect. I had already started thinking about this as I knew Kiss had such good annotations in it's gcode. I really hate slic3r so it's a good way forward, my only qualm is the apparent lack of developent with Kiss now, last time I looked, the forum was a spam-fest and it appeared that Jonothan had fallen off the map....
Without having a good look at your script, I would also need to apply a translation to the x/y coords for nozzle changes.

Thanks man

Yes Kisslicer does look dead now but what we do have is still good for as long as our printers don't change too much. Also the script does work on Cura as well, it does not have as many extrusion type markers (comments) but that may be something that Daid is willing to add.

For the coordinates I can see two being easy, four may be harder. You would return to a known set of X/Y coordinates and do a G92 Xnn G92 Ynn equal to the offset. Then on the next change you would return to the offset location and apply a new location.

If you provide me with the code you are currently using to switch extruders I will try and hack something up.

Edited 1 time(s). Last edit at 01/12/2014 08:01PM by Sublime.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

I gave writing it a try based on what I think is correct but I do not have multi extruder machine to test it. [github.com]

I have tested it on some gcode files and it does what I expect it too. It works with both Relative and Absolute extrusion. There are a bunch of settings you will have to fill out at the top of the file. It is well commented so it should be easy to set up. Let me know if anyone tries it.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

I realize now I need to add retraction as well as flow rate adjustment since the hobbed bolts will not be the exact same as well as the firmware not having independent steps per mm.

Should I add separate retraction settings for each extruder or one global one?
Should it compensate for filament diameter differences as well as hobbed bolt differences? Maybe slice everything with a fixed filament diameter (1.75 or 3) and then set the actual diameters in the post processor?

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Quote
Sublime
I realize now I need to add retraction as well as flow rate adjustment since the hobbed bolts will not be the exact same as well as the firmware not having independent steps per mm.

Should I add separate retraction settings for each extruder or one global one?
Should it compensate for filament diameter differences as well as hobbed bolt differences? Maybe slice everything with a fixed filament diameter (1.75 or 3) and then set the actual diameters in the post processor?

Both good questions - I would say that slicing with the same filament diameter would make sense and then scripting a flow rate reduction. At least as a short term approach - given that we can't set independent steps/mm per extruder in fimrware yet, we're pretty much bound to using the same type of extruder for each head at this point.

Incidentally, I'm currently using Airtripper direct drive extruders as I was getting a bit frustrated with Gregs style ones and they take up a lot of room on the chassis once you've got 4 running. This means the hobbed pulley is a consistent diameter so one less thing to factor in (for my purposes at least)

Yes to separate retraction settings - definitely need this as materials ooze at very different rates - my recent ABS-Tglase experiments have shown that tglase needs to retract 150% more than ABS and it still oozes a bit. I'd like to be able to have a wipe zone set up to clean the nozzles prior to starting a new nozzle. I was thinking of setting up a corner with a brush or blade the nozzles could pass over to remove any ooze and also possible prime the nozzle before printing. Any thoughts?

Appreciate you just jumping and writing some new code - I've alerted the E3d guys to this as it will e relevant to any Kraken experiments until the slicers catch up.

My wife was home today so I had time to add the features. It now has settings for each extruders retraction, filament diameters and gain. Let me know if it works for you.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Quote
Sublime
My wife was home today so I had time to add the features. It now has settings for each extruders retraction, filament diameters and gain. Let me know if it works for you.

Awesome, mine is in the final stages of a PHD so I'm not getting much spare time at present. I'll have go with the script this evening though.
Incidentally, if you were inclined, the relevant code in Cura that defines infill, perims etc is here , I've been talking to Daid on G+ and he recons it would be reasonably straight forward to hack it to differentiate extruders for infill etc. - I don't expect you to do this btw but I thought it might be useful thing to know

Hmmm

Ok, so i've got the script running and it changes the tool for infill but it also iteratively offsets each layer by a certain value in the X and Y axis relative to the previous layer - I thought it was the nozzle offset intitially but it's slight larger distance. if you stick a bit of processed gcode in repetier or whatever the problem is pretty obvious.
I had a bit of a look at the code but it's too late and my code-foo sucks anyway. I'm a little confused as to what the tool-change location (TCL_X TCL_Y) is for in this case as all tools are on board so we should just be offsetting the gcode by the tool head offset values right?

I'm sure its' a minor thing I should be spotting, I'll have another look tomorrow.

Well some of this could be a result of my misunderstanding of how Marlin handles the tool change and my assumptions. Like I assume you have no offset set in Marlin since it only allows for 2. If you do have all the offsets set in Marlin then you should set all the offsets in the post processor set to 0.

I should explain what I am trying to achieve. The following is an example of the code being inserted in my tests.

; Change tool for loops.
G1 E31.00955 F1800   <-- Retract
G1 X50 Y50 F6000   <-- Move to tool change location
M104 S130   <-- Set inactive extruder to idle temp
T1   <-- Select new extruder
G92 X15 Y50   <-- Tell the machine it is in a different location based on offset settings
M109 S210    <-- Set active extruder temp
G92 E31.00955   <-- Tell active extruder where it should be before un-retract
G1 E32.00955 F1800   <-- Un-Retract
; Set loop flow rate.
M221 S100

Next time it changes.

; Change tool for perimeter.
G1 E32.05635 F1800   <-- Retract
G1 X15 Y50 F6000   <-- Move to tool change location based on the last tool change G92 offset
M104 S130   <-- Set inactive extruder to idle temp
T0   <-- Select new extruder
G92 X50 Y50   <-- Tell the machine it is in a different location based on offset settings
M109 S210    <-- Set active extruder temp
G92 E32.05635   <-- Tell active extruder where it should be before un-retract
G1 E33.05635 F1800   <-- Un-Retract
; Set perimeter flow rate.
M221 S100

I think I may have the offset backwards right now. That is it assumes T0 is the furthest from X0/Y0 and it should be the closest?

As I was writing this I realized I have it setting the retract value based on the new tool not the one being deselected.

The tool change location was just an easy way to know where the head was before each tool change as well as make sure the hotend was not over the print while heating. It would not be much harder to take the current location and apply the offset directly to it.

I am not a programmer either and just hack my way through these things (although I get better every time). This script could be cleaned up a lot to use functions more but it started off as my previous one so it ended up being a little long winded.

I am not sure if any gcode previewer will ever show the code correctly since the coordinates are not being altered just the machines memory of where it currently is does.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

I've updated the script to fix the retraction issue as well as the backwards offsets.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

I installed Repetier host and loaded my test gcode. The results look exactly as I would expect. The test object is centered where it should be and the other parts are offset by the distance I have them set to (35mm offset). The extra lines are from the head returning to the tool offset location.

T0 = Blue is Perimeters and infill
T1 = Teal is Loops
T2 = Orange is support
T3 is not used in this example.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

I've sliced a model with new script and got it running remotely while I'm at work and what I could see on the webcam wasn't promising

For loops, perimeters and solid infill, where I'm using the same tool. It still go's off to TCL after every loop and waits to hit target temp - it then moves back to the part very slowly - I assume this is because it's the Feedrate associated the next G1 command (that starts the loop) that defines the travel speed from TCL.

So, things I was thinking of:

-Some logic that can work out when a tool-change is actually required based upon the tool choices, Currently I have T0 set for everything part from sparse infill. Kiss annotates every loop separately so for the shell, it makes 3 TCL moves to produce 2 loops and 1 perimeter.

-Maybe using M104 instead of M109 on toolchanges?

-Is is possible to read and record the XY values for the last G1 line before you apply a tool change? If you could record these values you could then switch to G91 to apply an x y offset relevant to the new tool, then revert to G90 and apply a G92 command that uses the recorded x and y values to reset the position? For the next tool change you do the same thing, only apply an offset relative to the previous tools offset.

I suspect this is non trivial but the code in it's current state isn't very useable because of all these toolchange moves.

After thinking about my previous posts I realized maybe we should return to the same point after changing tools at the tool change location.

I also moved the speed settings to be the first thing after the G command to match Cura and Kisslicer's output.

; Change tool for loops.
G1 F1800 E31.00955    <-- Retract
G1 F6000 X50 Y50    <-- Move to tool change location
M104 S130   <-- Set inactive extruder to idle temp
T1   <-- Select new extruder
G92 X85 Y50    <-- Tell the machine it is in a different location based on offset settings (reversed from earlier versions)
M109 S210    <-- Set active extruder temp
G1 F6000 X40.75 Y40.75 M109 S210    <-- Return to previous location before un-retract
G92 E31.00955   <-- Tell active extruder where it should be before un-retract
G1 F1800 E32.00955    <-- Un-Retract
; Set loop flow rate.
M221 S100

I also fixed a bug that meant the infill was not being printed by a different extruder with Cura.

T0 = Blue is Perimeters and infill
T1 = Teal is Loops
T2 = Orange is support
T3 = Blue but the infill


I was writing this when you posted so some of the issues are already fixed.

Yes it should be easy to add an if the tool has not changed statement to insure it does not change the tool over and over again to the current tool.

I can also make the M109 configurable. But if you have it cooling the unused hotend and try to print before it is up to temp it could be an issue.

I did not use G91 because as far as I understand it still keeps track of the Absolute position. But as you say we could then apply a G92 to fix the location. With the changes I just made it would be easy to eliminate the G91 and simply apply the new location and then move into position. Maybe I should add some logic that says if idle temp is 0 do not go to TCL?

Edited 2 time(s). Last edit at 01/14/2014 05:27PM by Sublime.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Quote
Sublime
Yes it should be easy to add an if the tool has not changed statement to insure it does not change the tool over and over again to the current tool.

Cool.

Quote
Sublime
I can also make the M109 configurable. But if you have it cooling the unused hotend and try to print before it is up to temp it could be an issue.

The idle temps are generally only what, 10 lower than extrusion temps? And it takes only a few seconds to get up to temp so I'd be prepared to risk it. Of course, this would be one of the reasons to have a prime tower or prime zone but for the sake of getting something going, M104 would be preferable for me at least.

Quote
Sublime
I did not use G91 because as far as I understand it still keeps track of the Absolute position. But as you say we could then apply a G92 to fix the location. With the changes I just made it would be easy to eliminate the G91 and simply apply the new location and then move into position. Maybe I should add some logic that says if idle temp is 0 do not go to TCL?

Yes, I don't see any need to go to TCL if we're not waiting to change temp.

Ok most of it is updated (configurable Temp code, do not change if already using the correct extruder), I just have to add the do not go to TCL if Idle temp = 0. That should be up some time today (wife is out with my Daughter and this is fresh in my head).

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Ok it no longer returns to the TCL when the idle temp is 0.

Let me know if it needs anything else or more bugs. And of course any results you get using it.

Remember when I said it would be easy to to modify my old script to do this? Well I was wrong and it was not as easy as I thought. It is now very different from the original script.

Re-link since the original link is way up the page [github.com]

Also if it all works I will try and add a (square) prime pillar in the TCL location.

Edited 3 time(s). Last edit at 01/14/2014 10:52PM by Sublime.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Ok it is all fixed and ready to try.

With the idle temp set to > 0 you can see it travels to the TCL


With the idle temp set to 0 you can see it does NOT travels to the TCL

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Progress!
It's changing tools and not moving to TCL that often. Current issue is it's not repriming T0 (perims) enough once it starts using T1 for sparse so the perimeters aren't being created. I'll do some more testing shortly.
It also does some very slow moves to loop start position just after tool change from T1 to T0.

Quote
jimjimma
Progress!
It's changing tools and not moving to TCL that often.

So it still happens sometimes when it should be disabled by 0 idle temp? Can you provide a Gcode snippet of the problem area?

Quote
jimjimma
Current issue is it's not repriming T0 (perims) enough once it starts using T1 for sparse so the perimeters aren't being created. I'll do some more testing shortly.

Does it seem like it is not un-retracting the amount specified for that extruder or is it that we need an extra on restart parameter? Do you use Relative E? If so I just found a bug that would cause this. If not can you provide a Gcode snippet of the problem area?

Quote
jimjimma
It also does some very slow moves to loop start position just after tool change from T1 to T0.

I can not see anything in the code that would cause this. Also the "from" section type (perimeter, infill, etc) would help more in this case because of the way the code is structured than the tool number. Can you provide a Gcode snippet of the problem area?

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

GAh - whole evening wasted sorting out some thermistor problems. WIll be another 24 before I can do some more tests. I noticed I had wipe enabled - that may have been causing issues. I'll post some sample GCode shortly.

Here is the original unprocessed file

and here is the processed one. I have had no time to look at it so far so it may be something blindingly obvious.

OK it was travelling to the TCL because the Idle temp was set to 210.

For the not enough priming at least on the first tool change it may be a result of the fact that your retraction length is greater then the Absolute E value so far at that point so it puts E into the negative which means if the software endstops are enabled it may be ignoring the -E and reducing the prime by that much. If so it is yet another reason why we should not use Absolute E (among many many more reasons not to and none in favour of it over Relative)

G92 E-0.3025
G1 F1800 E3.4975

For the slow movement I was missing a new line while re-inserting the ;Loop comment so it was missing the travel at F7800 and using the next speed of F210.

; 'Loop', 0.2 [feed mm/s], 15.0 [head mm/s]G1 X156.74 Y117.15 E3.4975 F7800
G1 X156.74 Y117.15 Z0.1 E3.4975 F210

I will update it a little later with all the issues fixed as well as a configurable prime pillar in place of the TCL

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Quote
Sublime
OK it was travelling to the TCL because the Idle temp was set to 210.

For the not enough priming at least on the first tool change it may be a result of the fact that your retraction length is greater then the Absolute E value so far at that point so it puts E into the negative which means if the software endstops are enabled it may be ignoring the -E and reducing the prime by that much. If so it is yet another reason why we should not use Absolute E (among many many more reasons not to and none in favour of it over Relative)

G92 E-0.3025
G1 F1800 E3.4975

As you know Cura doesn't do relative E and I use both Cura and Kiss which is why I'm using absolute. I entirely agree btw. In the short term I'll insert some start gcode that puts a thick line of plastic from x0y0 to X200Y0 for e0 and then return to X0Y0 while extruding from E1. That should prime the nozzles nicely and give enough positive E to avoid any negative E after early retractions.

Quote
Sublime
For the slow movement I was missing a new line while re-inserting the ;Loop comment so it was missing the travel at F7800 and using the next speed of F210.

; 'Loop', 0.2 [feed mm/s], 15.0 [head mm/s]G1 X156.74 Y117.15 E3.4975 F7800
G1 X156.74 Y117.15 Z0.1 E3.4975 F210

I will update it a little later with all the issues fixed as well as a configurable prime pillar in place of the TCL

So, I was thinking about this stuff last night. The print I ran before having thermistor problems was ABS shell with Tglase infill. Tglase and ABS don't bond so nicely but my prior experiments showed that a slight overlap at the point the infill meets the loop allowed (for what I assume is) a good mechanical bond. The same can't be said for the bond between the solid infill (ABS) at top and bottom and the infill, the stuff I produced last night peeled away quite easily (I've already considered the support material opportunities here btw). So, in order to overcome this, I think the first few layers and last few before solid infill should alternate between ABS and TGlase infill, possibly with the TGlase infill over extruding to ensure it pushes through the gaps in the ABS infill to bond with the tglase below....
I figured I'd just hack the pre-processes gcode to achieve this in for the time being but I'm interested to hear your thoughts. To me, the opportunities Kraken opens up are mostly related to multimaterial applications and FDM should allow for strong mechanical bonding of materials by ovelapping, offset hatching etc.

Quote
jimjimma

Quote
Sublime
OK it was travelling to the TCL because the Idle temp was set to 210.

For the not enough priming at least on the first tool change it may be a result of the fact that your retraction length is greater then the Absolute E value so far at that point so it puts E into the negative which means if the software endstops are enabled it may be ignoring the -E and reducing the prime by that much. If so it is yet another reason why we should not use Absolute E (among many many more reasons not to and none in favour of it over Relative)

G92 E-0.3025
G1 F1800 E3.4975

As you know Cura doesn't do relative E and I use both Cura and Kiss which is why I'm using absolute. I entirely agree btw. In the short term I'll insert some start gcode that puts a thick line of plastic from x0y0 to X200Y0 for e0 and then return to X0Y0 while extruding from E1. That should prime the nozzles nicely and give enough positive E to avoid any negative E after early retractions.

I do have a solution for this. [github.com]

Quote
jimjimma

Quote
Sublime
For the slow movement I was missing a new line while re-inserting the ;Loop comment so it was missing the travel at F7800 and using the next speed of F210.

; 'Loop', 0.2 [feed mm/s], 15.0 [head mm/s]G1 X156.74 Y117.15 E3.4975 F7800
G1 X156.74 Y117.15 Z0.1 E3.4975 F210

I will update it a little later with all the issues fixed as well as a configurable prime pillar in place of the TCL

So, I was thinking about this stuff last night. The print I ran before having thermistor problems was ABS shell with Tglase infill. Tglase and ABS don't bond so nicely but my prior experiments showed that a slight overlap at the point the infill meets the loop allowed (for what I assume is) a good mechanical bond. The same can't be said for the bond between the solid infill (ABS) at top and bottom and the infill, the stuff I produced last night peeled away quite easily (I've already considered the support material opportunities here btw). So, in order to overcome this, I think the first few layers and last few before solid infill should alternate between ABS and TGlase infill, possibly with the TGlase infill over extruding to ensure it pushes through the gaps in the ABS infill to bond with the tglase below....
I figured I'd just hack the pre-processes gcode to achieve this in for the time being but I'm interested to hear your thoughts. To me, the opportunities Kraken opens up are mostly related to multimaterial applications and FDM should allow for strong mechanical bonding of materials by ovelapping, offset hatching etc.

For now you could use 1 perimeter and 1 loop. Then in Kisslicer set the infill overlap to something higher than default so it overlaps the loop. Then reduce the flow of the loops in the post processor so you do not have too much material. This will at least increase the infill to wall adhesion. For the solid to infill it will take something like you say where it intermixes the two materials for a few layers.

I have uploaded a new version that has a configurable spiral square prime pillar. It currently has the limitation of needing a tool change on every layer to work. I will work on adding it to the layers without tool changes if it looks ok so far. Also note I have changed a lot of code and the variable names so you will have to re-read the settings notes while setting this version up the first time.

This is a visualization using [github.com] of the code with a prime pillar.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

That is great - I will get to try it out tonight. Can you PM me your email address? or Just email me directly, my address is somewhere on page5 of this thread. The E3d guys would like to show their appreciation for the work you've done on this as it's really going to help Kraken users until this sort of capability is integrated into slicers.

Thanks again, I know I keep saying thanks but I'm blown away by how helpful you are being here

Quote
jimjimma
That is great - I will get to try it out tonight. Can you PM me your email address? or Just email me directly, my address is somewhere on page5 of this thread. The E3d guys would like to show their appreciation for the work you've done on this as it's really going to help Kraken users until this sort of capability is integrated into slicers.

Thanks again, I know I keep saying thanks but I'm blown away by how helpful you are being here

PM sent (easier than finding your post)

I did this for you as well as myself. I really enjoy solving problems and learning. This has taught me a lot about programming in Lua as well as understanding the way a multi extruder machine works. I do have a large machine 80% finished that I plan to make multi headed when complete and these scripts will help a lot since I do not plan on using Slic3r any time soon.

For the intermixing of two materials we could add some logic that says do not change hotends for layers x, x, x, .... . Then add some more logic that says for skipped layers use Tn. For that to work you would have to except that for those layers it will print the entire layer with one single material regardless of how many different types would normally be called.

If I make all the code that writes out each section a separate functions it should be possible to say for layer x use tool n for section x of layer n otherwise use the current logic format of a specific tool for each extrusion type.

Also I think I have figured out (at least in my head) how to implement the prime pillar on layers without a tool change. I will try adding it next time I have the time to sit down and play.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Have you scaled up the Tantillus for your large machine or is it something completely different?

For the multimaterial 'bonding' layer changes. It had occurred to me that you could do an initial parse that performs an N+1 find and replace of the 'sparce' comment with 'solid' in the gcode for a configurable number of layers before doing any of the tool change processing. Hmm, in fact you could replace alternating layers with a pair of new comments called 'bonding_a' and 'bonding_b' or something similar; that way you could configure separate tool profiles that use the solid extruder and sparse infill tools but with configurable temperature and flow rate settings. This could be very useful as I suspect the inter-material bonding could be improved by raising the extrusion temperature of both materials so they interlock and bond better with the layer N-1 below.

Incidentally, I've been using this gcode viewer as it's browser based and easy to use, 3d view sucks but 2 view is very clear and it highlights the layers gcode as you scroll through in 2d mode.

Quote
jimjimma
Have you scaled up the Tantillus for your large machine or is it something completely different?

It kind of like the Ultimaker/Tantillus mechanisim except it does not have rods that rotate. Instead it uses 4 motors on X and Y with one for each side but tied together with a thin rod so they can not go out of step with each other. It is a very large machine made out of stuff I had lying around. Its print volume is 0.25m x 0.5m x 1m and uses a cable driven Z axis with worm drive reduction.

Quote
jimjimma
For the multimaterial 'bonding' layer changes. It had occurred to me that you could do an initial parse that performs an N+1 find and replace of the 'sparce' comment with 'solid' in the gcode for a configurable number of layers before doing any of the tool change processing. Hmm, in fact you could replace alternating layers with a pair of new comments called 'bonding_a' and 'bonding_b' or something similar; that way you could configure separate tool profiles that use the solid extruder and sparse infill tools but with configurable temperature and flow rate settings. This could be very useful as I suspect the inter-material bonding could be improved by raising the extrusion temperature of both materials so they interlock and bond better with the layer N-1 below.

Incidentally, I've been using this gcode viewer as it's browser based and easy to use, 3d view sucks but 2 view is very clear and it highlights the layers gcode as you scroll through in 2d mode.

Your method of replacing the comments would be the easiest to test the theory to see if it actually helps. If it does maybe I could add a field where you input an array of layer number and then an array of command to insert. Then you could use it for so much more like changing temperature, adding pauses, etc.

That gcode viewer is nice for the 2D display of the code created by the script.

I found another script that you may be interested in playing with [github.com] . It reduces the short segments by blending them together into straight lines based on some logic that I am yet to understand. The results posted on the page I found it on were more than impressive though. I think this is the page but I would have to delete all my cookies to view it again to confirm due to some issue with Google and Ad blocking / no tracking plugins I have enabled [groups.google.com]

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Found a bug, still getting no perimeters once the sparce kicks in.

; Change tool for loops.
G1 F4500 E-0.4617
T0
M104 S230
G92 X155.77 Y89.82
G0 F9000 X155.77 Y109.82
G92 E5.8383 <---sets previous E value for this Tool
G1 F4500 E9.5383 <---primes by specified value (3.7mm in this case)
; Set loop flow rate.
M221 S100
;
; 'Loop', 0.5 [feed mm/s], 44.4 [head mm/s]
G1 X156.74 Y117.15 Z1.9 E0 F7800 <------ E set to zero so filament retracts by 9.5383mm.
G1 X156.74 Y117.15 Z0.9 E0 F210
G1 E3.7 F6000 <------ prime by 3.7mm (Kiss prime value) but not makign up for the 9.5mm retract above.
G1 X125.93 Y117.15 E4.0633 F2663


I'm going to edit the toolchange function so it has a G92 E0 after the prime and we'll see if that makes a difference.