Multi Colour Printing without using wipe or prime towers
-
So as promised, herewith a link to the new blog that I have set up, in which I have created a post giving full details of my technique. The information should all be clear but if you have any questions, feel free to comment on the blog and I'll do what I can to help. https://somei3deas.wordpress.com/blog/
Please bear in mind that I only set the site up a couple of days ago and I've gone with the free WordPress plan which means I am very limited in what I can do with the design and layout. Also, apart from a brief introductory post, this is the first post I have ever made so I have much to learn.
Be warned that I'm not a programmer and if you use the Python Script which I have linked to, and it crashes your PC, don't blame me. Having said that, it works fine for me.
I give this information freely in the hope that others may benefit from my endeavours. If you find it useful, then a word of thanks or attribution would make an old man very happy.
-
It would be cool to have some kind of color/transparency sensor that could determine if the filament has reached the correct spot in the tool chain. Not sure what good that would actually do, but sounds fun.
Jeff
-
@(In)Sanity:
It would be cool to have some kind of color/transparency sensor that could determine if the filament has reached the correct spot in the tool chain. Not sure what good that would actually do, but sounds fun.
Jeff
I have no idea what that means or how it could help. Each of the filaments are loaded into the hot end as far as they can go which is the point where they all come together in the "mixing chamber". They have to be. If there is any gap, filament from one of the other inputs will be forced back up into it. So the distance from the end of the filament where it enters the hot end, to the nozzle tip is a fixed amount which never changes. Why would you need any sort of sensor?
-
So picture a sensor that can detect if the nozzle has reached a purity level and then can skip steps on the priming tower to not waste as much plastic, The next prime would just bridge if needed. This could allow variable priming. Such a sensor would be incredibly hard to accomplish short of a focused camera, or passing light through the filament. I have a Cyclops myself and so far I'm happy with it.
Yah I know this has nothing to do with your approach.
Jeff
-
After a bit more testing, I've made a bit of a discovery. I'm not 100% sure but it seems that the required "purge amount" needed to find the optimum tool change position is inconsistent, and that this inconsistency may be related to print speed. I've put a bit more detail in my blog https://somei3deas.wordpress.com/2017/01/16/update-to-blog-6th-jan-printing-without-wipe-and-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.
