-
TeamFDM.com is an UNOFFICIAL companion site for the DIY Voron 3D printer community. For official docs and final source of truth, visit the Official Voron Discord or the Voron Github
-
Welcome to TeamFDM.com
Welcome to TeamFDM.com, your premier destination for dedicated Voron support, guides, and discussions focused on the highly popular Voron 3D printers. As the largest Voron forum on the internet, we pride ourselves on being an independent resource for comprehensive tutorials and guides, providing an alternative to the Official Voron Discord or Official Voron Reddit.
Please note that we are not officially affiliated with or endorsed by the Voron Design team.TeamFDM.com is the perfect place for enthusiasts of all ages and skill levels to come together and explore the world of Voron Designed 3D Printers and accessories. Our thriving community, now over a year old, invites you to join us in welcoming fellow hobbyists as we work together to build, troubleshoot, and celebrate the incredible capabilities of Voron 3D printers.
Begin your Voron journey by visiting our forum (or bulletin board), where you can search for answers, ask questions, and receive support for your build. Discover the value of TeamFDM.com and the vibrant Voron community today!
-
Featured Topics
-
- 45 replies
- 39,339 views
-
- 5 replies
- 11,334 views
-
-
Vendor Forum Feed
-
- 53 replies
- 50,600 views
-
-
Latest Activities
-
87
Faster Printing requiring Filament Buffer feeding
Hi, I stumbled upon this thread quite by chance — thanks @therm_virtual0y for the boost on my repo, that's how I ended up here. First, a bit of honesty: the idea came from me — I use an LLL Buffer Plus and I wanted a truly autonomous auto-feeder that would remain Klipper compatible because I didn't want to do any wiring, so it emerged out of laziness — but the firmware itself was developed with a significant amount of AI assistance (Claude/Anthropic). This isn't hidden; it's visible in the commit history (Co-Authored-By). I prefer to mention it upfront rather than have someone discover it and feel misled. And I also build upon the work of depau/lll-buffed, river29, and others before me. Here's what this means in practice, so no one wastes time: - The autofeed runs autonomously within the MCU (Halls → TMC2208), so the feed doesn't wait for USB/Klipper round trips — this is precisely what helps with the synchronization issue in long prints mentioned by some here. - The runout is exposed to Klipper via USB (standard MCU): the best of both worlds — standalone reliability + host-side runout. - Power supply + USB only — no CAN bus, no I2C cabling to operate the autofeed. The shared firmware manages one buffer per board (via USB), it's not designed for the multi-buffer I2C control that @goofballtech is aiming for — his approach is better suited for setups with many coils. The project you're working on looks very interesting and will go through a lot of testing; kudos for the initiative.- 1
-
-
3
A custom toolchanger design for the Mercury Zero printer.
I’ve completely overhauled my project once again. Now it resembles something along the lines of Idex.- 1
-
-
656
Mini Stealth - Orbiter 2.0
Well done and thanks for the input. I will work on the parts you've pointed out so other people can benefit from your efforts.- orbiter 2.0
- v0.1
- (and 16 more)
-
656
Mini Stealth - Orbiter 2.0
It hits the rigid core right where I marked it. I was able to insert a small negative part in the slicer to get them to all fit. So other than wiring in the Neos and waiting on my fans, the heads are pretty much all built now. Just a few things I noticed while putting them together.- orbiter 2.0
- v0.1
- (and 16 more)
-
656
Mini Stealth - Orbiter 2.0
Did you try the mounts on the Nitehawk36 GitHub page? OrbiterMount- orbiter 2.0
- v0.1
- (and 16 more)
-

