Multi Colour Printing without using wipe or prime towers
-
This is a copy and paste of something that I have just posted on the reprap forums.
If my theory is right, then if the speed of filament through the extruder is constant the amount needed to purge the hot end will be constant. What I think is happening is that the melt zone effectively expands and contracts inversely proportional to speed of filament through the extruder, so the amount of filament needed to purge also changes. There is probably a time element in this as well. This is something that I had observed at the start of every print where there seemed to be "bleeding" of colours after printing the perimeters to purge each tool and then starting the print proper. i.e the first tool change or two. I thought it was an error in my script but I'm now leaning towards the theory that it is due to the long heat soak that the hot end is subject to while it is warming up which effectively increases the melt zone. This can easily be overcome buy increasing the purge amount for the first tool change or two but I need to do more testing to determine how much by.
The difficulty arises when there are significant changes to print speed, for example the fist layer is usually printed more slowly so more filament will need to be purged than for other layers. Having said that, it won't be a huge problem if some of the inner layers are slightly out, as long as the outer perimeters and visible surfaces are correct. What is obvious though is that if the "purge amount" is optimised for an object printed at 80mm/sec, then it won't work for another object printed at 40mm/sec. It is possible to get the correct purge amount for any object by trial and error but it would be nice to have an algorithm that calculates it automatically. So, I need to do a lot more testing to determine the relationship between extruder speed and purge amount required.
The thing that will really balls this up is that if the user changes the print speed after the script has been run and during a print. In which case, the purge amount needs to be dynamically variable in "real time" depending on extrusion speed and that could only be achieved through firmware and not by a static "pre-print" script. (are you listening dc42?) winking smiley
In the end, it may be that a small wipe of prime "tower" or mechanism is still required but it won't need to be anything like as large.
-
Ian
Sounds like you are really getting into the details. My idea for working this out is to print a pattern with varyingly long elements, colour changes at a constant point at the start of each element of the pattern. That way the user can say that leg (say) 5 of the pattern had the colour change happen exactly at the corner. Each leg would correspond to a specific colour change purge length.
An array of these patterns could then be printed for each colour combination desired, and speed desired, and the script would take these user inputs to inform how far in advance to time the change.
I can draw a picture if that helps
-
Ian, I think the change in position of the purge zone is related to pressure advance. Suppose you are doing a long straight printing move at high speed and the filament needs to be switched in the middle of it because a colour change is required some time later. With pressure advance enabled, the old filament will be pushed more gently just before the change, or even retracted, while the new filament will be fed in more vigorously at the start. If you don't use pressure advance then the changeover will be delayed because of the elasticity of the filament in the Bowden tube.
So you could try increasing pressure advance, and see if you can find a value that gives you a constant purge length. The right amount of pressure advance should also make the colour change sharper.
-
No worries Tony. I have a test piece that works very well and it's similar to what you had in mind.
It's essentially two rectangles inside a larger rectangle. Or put another way, one large rectangle (more or less square) with two rectangular (oblong) cut outs which is one colour, then each cut out is filled with a rectangle of a different colour. This give 3 colours and lots of changes between the various colour combinations within the same layer. When it is printed, it always end up filling in a small corner of a rectangle before starting the next rectangle so it's easy to spot if the purge is too much or too little. It's how I tuned the purge before printing the Union Jack.
All I need to do is run the script on the native gcode for that object (don't even have to slice it again) with "purge amounts" from say 2mm to 10 mm in 0.5 mm increments. That'll give me 20 or so files with different purge settings (tool change positions) but otherwise the same. Then if I print the object at say half speed using a different file each time, by iteration I should find the optimum purge setting for that speed. Repeat for other speeds and I'll end up with a matrix of speed/purge settings. Hopefully, I'll find a linear relationship between speed and purge which should be relatively easy to compensate for. The script would then (probably) interrogate the gcode file to find what the extrusion speed is prior to the tool change, then adjust the "purge amount needed" accordingly. (Not sure if I explained that well but hopefully you get the idea).
Cheers
Ian -
Ian, I think the change in position of the purge zone is related to pressure advance. Suppose you are doing a long straight printing move at high speed and the filament needs to be switched in the middle of it because a colour change is required some time later. With pressure advance enabled, the old filament will be pushed more gently just before the change, or even retracted, while the new filament will be fed in more vigorously at the start. If you don't use pressure advance then the changeover will be delayed because of the elasticity of the filament in the Bowden tube.
So you could try increasing pressure advance, and see if you can find a value that gives you a constant purge length. The right amount of pressure advance should also make the colour change sharper.
That's very good point David. From what I have observed, I don't think it's the whole story though it could well play a part. I definitely need more purge at the start of a print, when it changes from doing the outer perimeters to doing the perimeter of the print proper, which is essentially the same moves just inset a bit and then after that, the purge seems to work OK. I put this down to the extended heat soak with no filament moving through the nozzle during the warm up phase.
On the other hand, filaments that aren't being used will be sitting in the melt zone a long time, so the effective size of the melt zone for those filaments should be fairly constant regardless of print speed (because those filaments are static), which means that pressure advance may indeed be an important factor. I have to say that when the purge amount didn't seem to be enough, I was printing at a slow speed. What I hadn't considered (until now) is that the reason I was printing so slowly was because the object was mostly thinnish sections with very short print moves. I could well have put 2 and 2 together and made 5.
Lots more experimenting and testing to do - roll on retirement when I will have more time….....
P.S. thanks for the tips guys.
-
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.
