Multi-colour/multi-filament printing for Centauri Carbon
We calculate the final price from your selected file. You review and accept it before payment.
Saved on this device.
This is a fully working solution for multi-colour (or multi-filament) printing on the Centauri Carbon printer.
- Rating
- 0 / 5
- Likes
- 12
- Downloads
- 27
- Makes
- 0
- Views
- 876
- Reviews
- 0
Updated at source:
Model information
- Source
- Printables
- Category
- Other Printer Parts & Upgrades
- License
- Creative Commons — Attribution
Edit: April 26/26
I finally got a workable solution for keeping the excess filament tidy and not tangling when unloading. I re-mixed a couple of items on Printables - all detailed here.
I have also finalized both the GCODE start/end/change scripts and the exclude areas to make sure the micro-switch is not accidentally hit when printing large items.
Edit: April 12/26
After many, many filament changes, I came across a problem: When the autoloader pushes filament into the extruder, I have set the time for loading to make sure that the filament is put under compression against the printer extruder - to make sure that the printer extruder can 'grab' the filament and start pulling it. This works 100% reliably. However, while the filament is under compression for a second or so, there is a weak point in the chain - the friction fit of the ptfe tube into the output of the autochanger. The result was that the tube started pulling out and kinking the filament. And, of course, once this had happened once, it slowly got worse until it was basically unusable.
So, inspired by timb8907's design for a PTFE quick-fit adapter, I re-spun the C part to integrate the threads for the M6 PTFE connectors into the autochanger. There is only just enough room for the PC4-M6 connectors to screw in - and it's vital that you orientate the nuts so they slide over each other, but this works perfectly.
So, a V2 version of the C part is now included with these adapters.
Edit: April 4/26
Hmm...it seems that, in an effort to "tidy up" my setup with the 'Filament Terminal', I made the system unreliable. The reason is probably obvious: if the tubes are neatly tied down then there's nowhere for the filament to go when it retracts except into the dry boxes. This works up to a point - the point at which it gets tangled and jams - doh! For now I've removed the Terminal and simply used two lengths of tube 1 from the dry box a foot away from the selector input and then another length from the selector with the filament loaded across this gap. In use now the retracted filament does just fall down but relatively tidily. The unexpected advantage of this gap is that you can easily see the process running from the shortening and lengthening of the filament between the two lengths of tubing.
If anyone has any smart ideas for improving that situation then, I'm all ears.
I have the version 1 Centauri Carbon. Although I didn't originally purchase purely on the basis of the promised multi-filament upgrade, I was nevertheless disappointed that Elegoo haven't (yet) honoured the upgrade.
I searched for open source multi-filament upgrades and found the 3DChameleon. This was originally a kit of parts but now has been released as fully open source by the designer. Here are all the design files that I used as the source of the project: https://github.com/3DChameleon/3DChameleonMk4
I have designed parts to mount the full autochanger assembly on the right side of the printer, utilising the filament reel mounting hole and a couple of side panel mounting holes.
For the 4-way splitter I have used a design by HAIX3D -
I tried several 4-1 PTFE splitters and this one worked by far the best and had a convenient mounting bracket that allowed it to be mounted on one of the right hand cover panel screws.
I printed a microswitch mounting bracket that allows the print head to do all the filament selection and feed. And, after many trials, I have come up with a set of GCODE modifications to OrcaSlicer that reliably selects a filament, feeds at the start, unloads at the end and changes easily between filaments for colour (or material) changes. Surprisingly I found the most useful feature of having the autochanger is to load up my four favourite filaments and then just select the appropriate tool number in OrcaSlicer and send to the printer without finding and loading the right spool.
Challenges:
I encountered a number of challenges that I solved in the following ways:
When I printed the original B and C parts I noticed that filaments 0 and 1 would feed well but 2 and 3 would feed badly, often just stopping or unable to cope with any resistance in the path. On close examination of the mechanism I noticed that 2 and 3 were not compressing to the same extent as 0 and 1 and thus not giving enough pressure on the spring head. The solution I came up with was to re-mix parts B and C to effectively shorten the distance between the two bearings. This solved the problem completely. I still don't know if the issue is a fundamental design flaw or a tolerance build-up in my printer - the difference seems too stark for the latter.
The next problem I encountered was a strange dragging retraction on tool 0 when tool 3 was feeding. Again this looked like a design issue but I couldn't figure out exactly how to solve the issue in hardware. So, I effectively 'hacked' the firmware to back off a slight amount when selecting tool 3. Again this solved the problem completely.
The next problem is obvious: in order for the 3DChameleon to retract the 'old' filament and load the 'new' I needed to cut the filament. Now, the Centauri Carbon has a neat filament cutter that works well. But, Elegoo have not made the cutting process publicly available it seems, the entire cut and unload process is baked into the firmware and not available to Gcode. So, I had to effectively reverse engineer the sequence. I figured out both the X-Y co-ordinates necessary to move the head into the cutting position and the speed in order to make this work reliably and simply added this sequence to the Gcode. The only cosmetic issue is that, as soon as the Centauri detects that you are trying to move into the 'non-printing area' it gives you a warning about this on the screen. On my OpenCentauri firmware you can simply ignore this and it goes away later but I don't know if the stock firmware complains more strongly about this.
Next I came across the problem of trying to synchronise loading filament with feeding the Centauri's extruder. In the end I decided that this wasn't possible (not least of which because the head would be away from the poop-chute when doing this) and so I opted to just feed for a timed period until the filament had hit the extruder for a second or so. This, unfortunately could push the PTFE tubes out of the selector head. I solved this by printing a small restraining block for the 4 PTFE tubes. This arrangement works perfectly, I have had hundreds of loads or filament changes without a single issue.
So, the full list of my modifications from the 3DChameleon Github project:
Added a mounting platform to fit the Centauri Carbon.
Added a microswitch bracket for the Centauri Carbon.
Tidied up the firmware to remove unused sections
Modified the B and C parts to give greater pressure on T2 and T3.
Added a 'hack' for phantom retractions of T0 when T3 was loading.
Designed a "Terminal" panel for organising the 4 PTFE tubes from the dry boxes. This simply screws onto the IKEA Lack table I use for my printer.
I doubled the extruder speed since the path for the filament is quite long and this significantly sped up multi-filament print time.
I change microsteps from 16 to 32 in the firmware file. 16 did not work correctly with my steppers.
A word about the G-code files:
I have spent some time optimising the attached Start, End and Change Filament Gcode files. These should replace the standard ones in OrcaSlicer. If you have mounted the printed parts as I have, you are using the stock PTFE tube to the extruder and you have used my .ino firmware file with the double speed extruder mod then the load and unload times should work. If yours is not exactly like mine then you may need to change the microswitch hold times for loading and unloading. When setup correctly the load of the filament should push the end into the Centauri's extruder about a second before the head moves away and start to pull the filament in. When unloading, the filament should stop a centimetre or so before the 4-way splitter (and this is the point you should load the filaments to when setting it up).
When all is working correctly the selected filament should load and the printer starts printing. At the end the filament should simply extract to just before the 4-way splitter.
Things I've learned about the 3DChameleon:
Because the stepper drivers are enclosed and the selector stepper is always engaged, unless you correctly set the current pot on the driver board, the driver or the stepper will overheat (they shut down gracefully but you don't want that to happen mid-print!). Set the pot so that you have 0.5V on the potentiometer body and this equates to 1A motor current - plenty for this application.
I found out that the microstepping in the original source firmware is set wrongly - this would result in the selector only going half way around and thus not selecting the right tool. In my modified file I have set microstepping to 32 - this works correctly with my steppers - YMMV.
Note: Make sure to set up Orcaslicer for Single Extruder Multi Material with Manual Filament Change and turn on the Purge Tower.
I believe I have uploaded all files used, along with some photos and a video of a change procedure.
Future advancements:
In order to make this work, I have had to remove and disable the stock filament sensor. Now, it should be possible to integrate filament sensors (either a single one after the splitter or multiple ones before) but the issue is that there is no simple way of pausing the printer if a problem occurs. There is a solution for pausing the printer remotely developed by harpua555 on Github (https://github.com/harpua555/OpenFilamentSensor) but this would need a complete re-spin of electronics and firmware to achieve this. This may be a future project for me if I think it needs it.