Multi Colour Printing without using wipe or prime towers
-
Nice print! Let me guess: you have measured how much filament you need to extrude after a colour change before the new colour takes effect, and you have pre-processed the gcode file to move the tool change or tool mix ratio gcode earlier in the gcode fie to compensate?
If I am right, then it would be nice to do this in firmware. To do it in real-time would require having a queue of pending gcodes long enough to always use up sufficient filament, which could be tricky if the slicer generates a lot of short segments just before a colour change. However, as the firmware already supports simulation mode, perhaps it could run a simulation and then store the colour change points for use when printing.
-
Having firmware look ahead for tool changes has another advantage: allow the new tool to start heating to its active temperature so its temp has just stabilised (and potentially the purge has happened) as its required. That way it can wipe and print directly. While this does not apply to the diamond arrangement it would speed up IDEX printing.
-
Nice print! Let me guess: you have measured how much filament you need to extrude after a colour change before the new colour takes effect, and you have pre-processed the gcode file to move the tool change or tool mix ratio gcode earlier in the gcode fie to compensate?
If I am right, then it would be nice to do this in firmware. To do it in real-time would require having a queue of pending gcodes long enough to always use up sufficient filament, which could be tricky if the slicer generates a lot of short segments just before a colour change. However, as the firmware already supports simulation mode, perhaps it could run a simulation and then store the colour change points for use when printing.
Yes, that's pretty much how I'm doing it. The devil is in the detail though. Firstly I have to detect when it's a tool change and not just the first tool being selected 9or the same tool being reselected). I also have to ignore any pre and post comments and commands which might select or deselect tools). Finding the true start and end of the printing part of the file is trickier than one might at first imagine - especially when your consider what people might have in their start and end gcode files. I deal with this by having flags as the last line of the start gcode and first line of the end gcode in my slicer but there may well be a more elegant way of doing it.
The really tricky bit is that invariably the tool change needs to happen in the middle of a move. For short moves, it might not matter too much but for longer moves it'd be no use putting the tool change before or after such a move. So what I do is split the move at the the file insertion point - that is to say replace one G1 Xnn Ynn Enn with two new lines such that X and Y start and end at the same place but there is an intermediate step. The second part of the step contains the "E" amount needed to make up the total required purge amount. The first part of the step is the difference between that E amount and the original E amount from the line that is being replaced. X and Y are calculated accordingly by the same proportion. Of course another added complication is that the values for X and Y in the gcode file are absolute so I look at the previous line to calculate the relative X and Y moves in order to calculate the proportionate moves in absolute terms (not sure if I explained that well). Yet another added complication is that the previous line may not be a G1 Xnn Ynn Enn move. It may be a fan switch command or something else so it needs to be ignored and the line previous to that used. The same applies when trying to derive the sum of all the "E" values - lines which don't have an E value have to be ignored.
As you say, doing it real time would mean building a queue of pending gcodes in order to get the sum of the required purge amount, but could firmware deal with creating new G1 Xnn Ynn Enn lines where the required insertion point is somewhere in the middle of a move? It'd be real cool if it was possible though. More than happy to share what I've done so far.
Ian
-
Having firmware look ahead for tool changes has another advantage: allow the new tool to start heating to its active temperature so its temp has just stabilised (and potentially the purge has happened) as its required. That way it can wipe and print directly. While this does not apply to the diamond arrangement it would speed up IDEX printing.
If it's not possible in firmware, it'd a piece of cake to do adapt my method and do it by post processing the sliced gcode.
-
I think a solution would be to have two gcode buffers reading from the file. One would be in advance of the other and its function would be only to count the filament extruded and look out for tool change or mix change commands. At each such command it would subtract the purge length from the filament extruded to give the point at which the change needs to be made, and store that in a queue along with details of the tool change or mix change command. The second gcode buffer would do the actual printing and look out for when the filament extruded reaches the amount given at the head of the queue.
RRF is already able to segment moves, because it has to do that when applying grid based bed compensation to moves that are longer than the grid spacing. So splitting a move in two to do a tool or mix change in the middle wouldn't be a problem.
I'm not sure we would have enough free RAM on the Duet 0.6/0.8.5 to implement this, but we would on the Duet WiFi.
-
A couple of things. This method isn't perfect. For one thing, there is no allowance for the transition between one filament and the next. In practice, at least with the Diamond hot end, the transition is so small that it is hardly noticeable. Other hot end designs may have larger or more active mixing chambers which might mean that the transition between one colour and the next would be noticeable. The other thing that will screw it up is if there are insufficient moves between tool changes to fully purge the filament. The object would need to some pretty small coloured sections for this to be a problem but it's possible.
So I'm thinking that there may well be a requirement for some sort of very small wipe or prime mechanism in conjunction with what I've done so far. I'm planning to see if I can build something in which will generate some sort of a small purge mechanism (but nothing as large and wasteful as a full wipe/prime tower).
Note that these issues only become apparent when changing colours within the same layer and where that layer is visible on the finished print. If the colour change happens at the layer change boundary, then it's just a matter of setting the slicer to give 2 or more perimeters and to do the inner one(s) before the outer one.
Ian
-
While this can be done in Firmware as David suggests, is it not better done by the slicer for the reasons Ian points out?
-
I guess if it's easy enough enough to implement "look ahead" tool changing in firmware, then it would be a good thing to do and it might well suffice for many situations. There is probably no single best solution but perhaps a combination of firmware and some additional post slicing / pre-print processing may be the way to go. In any case, I'll keep trying to develop the post processing route because it may be helpful to RepRappers who aren't using Duet firmware.
-
… The other thing that will screw it up is if there are insufficient moves between tool changes to fully purge the filament. The object would need to some pretty small coloured sections for this to be a problem but it's possible.
I don't see why a short sequence of moves in a colour before changing the colour again would be a problem. It just means that there may be more than one tool change in the pipeline.
-
… The other thing that will screw it up is if there are insufficient moves between tool changes to fully purge the filament. The object would need to some pretty small coloured sections for this to be a problem but it's possible.
I don't see why a short sequence of moves in a colour before changing the colour again would be a problem. It just means that there may be more than one tool change in the pipeline.
What I mean is that if the amount of filament to be extruded between colour changes is less than the amount needed to purge out the old, then extra purging "off print" will be needed (I think - but maybe not). Say for example you were to print a face and the eyes alone were in a different colour to anything else, and those eyes only needed (say) 4mm of filament but 5mm was needed to purge out the old. I guess all the filament for the eyes plus part of the next colour would be held in the "purge zone" of the hot end. Maybe it would work. Dunno, I'll test that scenario when I get chance.
-
Say for example you were to print a face and the eyes alone were in a different colour to anything else, and those eyes only needed (say) 4mm of filament but 5mm was needed to purge out the old. I guess all the filament for the eyes plus part of the next colour would be held in the "purge zone" of the hot end. Maybe it would work. Dunno, I'll test that scenario when I get chance.
That's what I had in mind. Treat the melt zone and nozzle as a pipeline. Your scheme relies on the approximation that the colour mix that goes into the melt zone comes out of the nozzle a fixed distance (i.e. length of filament) later. You may have more than one colour change in the pipeline.
Let me know how well this scheme works out so I can decide whether/when to implement it in firmware.
-
Yes I'll do some more testing/refinement and get back to you. Not sure when that will be as my wife recently had surgery so I'm having to be chief cook and bottle washer (and cleaner, carer etc).
-
Clever idea Deckingman, I like it.
One more complication I noticed. Different filaments need different purge lengths. For instance when I am switching from black to white, I need to purge a hell of a lot more than when going from green to blue, for instance.
No idea if that is the case with all hot ends, not having a Diamond I can't test it.
Also, how is this with different types of filaments? Is ABS easier or worse than PLA, for instance. -
Hi Lykle (yasoo file mou)
No problem with different coloured filaments on the Diamond - can't really see why different colours of the same filament would need different purge lengths. I suspect the purge length you need for Black to White is correct and using less with Green/Blue probably means that they aren't fully purged but you can get away with it because a bit of Blue mixed in with Green probably doesn't show up. Funnily enough, I've just finished a door sign for my Hairdresser (well it got me a free haircut), not Black and White but Black and Silver (that's what the filament is called but it's light grey in fact). I used the same purge setting as the Union Jack. It's not perfect - there is a bit of Black round one of the screw holes which shouldn't be there) but it's not far out. Here is a link https://youtu.be/naiLL9qYeTE.
Maybe something weird happens with different dyes but I've not yet come across that problem. Having said that, I have only done limited testing so far and it's early days.
Can't comment on filaments other than PLA. I can't think of any logical reason why the same method wouldn't work though.
Ian
-
Yasou!
OK, so the Diamond head is definitely a different beast than my lowly V6 lite.
Good to know. I should try and upgrade but way to busy at the moment.If you want to try out different filaments that feel completely saturated with colour, you should try nGen. It feels as if you are printing colour particles instead of plastic. Their white even gives the impression of being "chalky". It isn't but that is what it feels like.
(btw, was thinking of designing a very compact 3 filament Nimble, good idea?)
-
Yasou Lykle,
Purging during tool change with a mixing hot end is a lot different to purging out a single filament to be replaced with another. I think that's maybe led to a bit of misunderstanding. For sure, when you want to change one filament for another it takes quite a lot to purge all trace of the old filament out of the hot end. But when you switch from one loaded filament to another, you only need to purge the small bit of filament that is in the mixing chamber and from the mixing chamber to the nozzle tip. I was quite surprised myself when I started testing on how little this actually is. For example, when loading a new filament I'll extrude 50mm or more before the new colour is complete;y clean of all traces of the old. However, when switching between one loaded filament and another, it takes only around 2.5mm. From observation, the "transition" between one filament and the other is I'd guess only about 10% of that so around 0.25mm which in most cases is hardly noticeable. Of course, other "multi input" hot ends might have larger mixing chambers and need more purging, so there may still be a need for some sort of small sacrificial "tower" if there is a large transition period between filament changes. The Diamond doesn't really have much of a mixing chamber - it's about 2mm long. This is both an advantage and a disadvantage in that the filament doesn't actually get mixed but rather, comes out like stripey toothpaste.
Not sure how a 3 filament nimble would work. You need to drive each filament independently and feed each one to a different heat sink/input on the hot end.
Ian
-
Clear.
Wonder if changing the position of the filament feed holes will change the stripey aspect. Doubt it. Will probably need a screw in nozzle option to make real mixing an option. Looking at the corkscrew shapes they force plastics through to mix properly, it might be a bit too big.
3 filament Nimble. Just a small block that holds 3 complete Nimble mechanisms. But the idea is a bit silly as it will be just 3 extruders coupled to the hot ends with bowden tubes. Only advantage is that the extruder block is very small. OK enough about this.
One more thing on the color changing. Just a comment on the cleverness of the people here.
1 you thought of it and tried it.
2 David and Tony took one look and realised what you are doing.clever.
-
Clear.
One more thing on the color changing. Just a comment on the cleverness of the people here.
1 you thought of it and tried it.
2 David and Tony took one look and realised what you are doing.clever.
Thanks - I'll take that as a compliment. As an ex automotive engineer, self taught in writing code and everything else, currently scratching a living by cutting and screwing bits of wood together, and too many years the wrong side of 60, I need all the encouragement I can get.
-
Ian
I have just ordered a Diamond Hotend for the CoreXY Build that I intend to resurrect after Xmas so may well be chasing you for configs etc when the time comes
-
Ian
I have just ordered a Diamond Hotend for the CoreXY Build that I intend to resurrect after Xmas so may well be chasing you for configs etc when the time comes
Any time Doug - you know my email address. I've got my machine pretty well dialled in. Of course, if there is info you need that might benefit others, then post here and I'll reply here.
Ian
