Multi Colour Printing without using wipe or prime towers
-
A further update on this if anyone is interested (judging from the lack of visitors to my blog and the complete absence of any comments, likes or followers, I'd say that not many people are interested).
Anyway, I've done some testing and the issue that I had noticed isn't speed related. Full details on my blog here https://somei3deas.wordpress.com/2017/01/16/update-to-blog-6th-jan-printing-without-wipe-and-prime-towers/
If nothing else, the last picture on that post shows a close up of the technique as good as it'll ever get, due to the transition period between colour changes. I don't think it's bad but whether it's acceptable is up to each individual to decide.
Ian
-
Ian
"reasonable amount of filament extruded between tool changes but cannot cope with tool changes that are too close together."
That makes complete sense, after all if the previous change has not finished purging then another change will end up with a mix between the new colour and the purge (which is part way between colours), or am i not getting this right?
-
Hi Tony,
Yes sort of. At least that is the way the script works now but it doesn't have to be that way. The best way to describe how it should work is how David suggested to do it. That is to have 2 streams. One is the raw input stream which is essentially delayed a bit, the second has the tool changes moved forward. Basically as it is, the script won't move a tool change to a position prior to the previous tool change. However, what it doesn't "remember" is that the previous tool change has now itself been moved to a position earlier.
One should be able to move all the tool changes forward by say the equivalent of 2.5mm of extruded filament, regardless of the fact that there may only be 1mm of filament between some of those changes. The only proviso being that there is more than 2.5mm of filament extruded before the very first tool change occurs. The offset if you like, is constant but the script as it stands doesn't work quite that way. Edit - Substitute the actual purge amount needed for the 2.5mm used in the prior example statements.
Not sure if I've explained that very well.
Ian
-
Ok yes, now I see.
-
Ian
Please don't be put of by lack of visitors to your Blog?
I for one haven't visited yet as I am nowhere near ready to start playing with it but you can be sure that it will get regular visits when I am ready?
Doug
-
Hi Doug,
I'll persevere with the blog for a bit longer but it is starting to feel like I'm wasting my time. It takes quite a bit of effort and all I'm doing is sharing my experiences in the hope that others may benefit, so I get nothing out of it.
I have a bit of a plan to produce a few things in order to generate a bit of income when my body finally breaks and I can't build decks any more. Nothing serious- just a bit of income to supplement my pension. So in a way I'm tempted to keep what I learn to myself. On the other hand, I've only got to where I am because of the whole RepRap movement so it's good to give something back.
At least I went down the free Wordpress route with the blog, so it isn't costing me any money - just time.
Ian
-
Ian
I Totally get where your coming from
-
Just had a read of your blog, it's very good. I'm not yet using mixing hotends but you can be quite sure if I do I'll read it again and make notes. Keep it up.
I wrote a blog about my electric car which people still message me about now, even though it's been over a year since I wrote anything new.
-
Quick update. I've re-written much of the script, fixed the issue(s) and it's working well. I guess it's still pretty ugly as I know next to nothing about writing code but it gets the job done.
As well as the issue with tool changes being close together, I found another couple of problems. The first was that I had made an error when segmenting moves. The E value was apportioned correctly between the two new lines, but the X and Y values were not. The second issue was that under certain circumstances, the tool change position was being inserted after a fast non-print move but before a "G1 F" command which would have resulted in a couple of print moves at 350mm/sec (would have been fun to observe).
All these issues have been fixed. The final test I did was on a file that had 428 tool (colour) changes spread over 154,000plus lines and I ball aching checked every single tool change in the entire file to make sure it was right. More details on my blog if anyone is interested (see signature).
Ian -
Hi Ian…thanks for the hard work and contributions. If I understand the process correctly, you are taking the slicer G-code and inserting your tool change routines at points that correspond to where color changes are expected. Having not yet worked with slicers or G-code I'm unaware of the coding sequences that you describe using Python scripts. Am I missing the entire point of how this works...? Thanks...Terry.
-
Hi Ian…thanks for the hard work and contributions. If I understand the process correctly, you are taking the slicer G-code and inserting your tool change routines at points that correspond to where color changes are expected. Having not yet worked with slicers or G-code I'm unaware of the coding sequences that you describe using Python scripts. Am I missing the entire point of how this works...? Thanks...Terry.
Hi Terry.
You are sort of on the right lines. If you take a gander at my blog, you'll see a post I did on generating gcode files for multicolour objects so I won't go into the details here. The slicer will generate the tool change commands and insert them into the output file. This assumes that the colour change will happen as soon as the machine receives a tool change command. If you have separate hot ends, each loaded with a different filament and each one defined as a separate tool, then this would work fine (apart from the fact that you need to wait while one tool heats up from a lower standby temperature). There are other issues with using separate nozzles but I won't go into those either except to say that you can get unwanted oozing from unused nozzles so it is usually necessary to use some sort of wipe of prime tower.
The advantage of having a single nozzle with multiple inputs, is that you don't have to wait for one tool to cool and another to heat up and you don't have issues with unused nozzles scraping over the print etc. The issue is that if you use a mixing hot end, i.e. a single nozzle but multiple filaments, then when you change tools, there is still some of the old filament left in the mixing chamber so effectively there will be a delay before the new colour comes through. Again the "traditional" approach is to use some sort of wipe or prime tower, but this involves retracting the filament, moving the head to a position away from the print, extruding some filament until the new filament comes through, retracting again, the moving back to the object and resuming printing. This is very difficult, maybe even impossible, to do without leaving a blemish of some sort on the print.
So essentially all I'm doing is taking the gcode file with the tool change gcodes already inserted, but then moving these tool change commands forward in the file. The aim being to change tool at the precise point on the file where the old filament will be purged by the time the new colour is required - not sooner and not later.
This negates the need for any sort of wipe or prime tower. The only thing I can't do is compensate for the fact that there is slight transition where the colour is a mixture of both old and new. However, my work so far has found that this transition is very small (at least it is with the Diamond hot end) so the affect on the quality of the finished print is very slight. In my opinion the print quality is superior to the blobs or blemishes that result in using wipe or prime mechanisms (towers).
Ian -
Thanks Ian…I think I understand the concept. So at the advanced tool change, the current color filament is retracted and the new color filament begins to push to the nozzle end, all the while continuing to eject the old color until it if fully expelled at the desired point in the print. Your calculations of the volumetric characteristics of your hot end of choice determines how far in advance the tool change is positioned in the gcode ahead of the slicer generated position. How are you effecting replacement of the gcode tool changes? Manually or through a programming script of some kind? If code, how do you apply that to the slicer generated file? Thanks...Terry.
-
Hi Terry,
You are kind of there with your understanding except that there is no retraction of filaments. I've explained the process in great detail in my first blog post which I have made a sticky on my web site. So to save me a lot of typing, you'll find all the answers to your questions here https://somei3deas.wordpress.com/blog/. HTH
Ian
-
I'm a little late to this party but this is a great idea and a clever implementation! Looking forward to giving it a try once I get my swapping working more reliably.
-
I'm a little late to this party but this is a great idea and a clever implementation! Looking forward to giving it a try once I get my swapping working more reliably.
If you are swapping filaments, i.e. retracting one and then feeding in another, you will need purge and/or wipe towers so this technique may not be of much use. You may find that you can reduce the size of the wipe/prime mechanism a bit but that's about the only gain. See the link above to my blog post for a full explanation of how it works.
-
If you are swapping filaments, i.e. retracting one and then feeding in another, you will need purge and/or wipe towers so this technique may not be of much use. You may find that you can reduce the size of the wipe/prime mechanism a bit but that's about the only gain. See the link above to my blog post for a full explanation of how it works.
Oh I know I'll still need a prime tower (or equivalent), but with your technique I would waste a lot less filament.
