X-Printer Fits In A Backpack

3D printers are great for rapid prototyping, but they’re not usually what you’d call… portable. For [Malte Schrader], that simply wouldn’t do – thus, the X-printer was born!

The X-printer is a fused-deposition printer built around a CoreXY design. Its party piece is its folding concertina-style Z-axis, which allows the printer to have a build volume of 160x220x150mm, while measuring just 300x330x105mm when folded. That’s small enough to fit in a backpack!

Getting the folding mechanism to work took some extra effort, with the non-linear Z-axis requiring special attention in the firmware. The printer runs Marlin 1, chosen for its faster compile time over Marlin 2. Other design choices are made with an eye to ruggedness. The aluminium frame isn’t as light as it could be, but adds much needed rigidity and strength. We’d love to see a custom case that you could slide the printer into so it would be protected while stowed.

It’s a build that shows there’s still plenty to be gained from homebrewing your own printer, even in the face of unprecedented options on the market today. We’ve seen other unique takes on the portable printer concept before, too. Video after the break.

14 thoughts on “X-Printer Fits In A Backpack

  1. Now, someone should run with this idea and make a 3D printed version, like the original RepRap.
    I’d trade some speed in exchange for a low-cost, yet large format version of this.

    1. Thats not comparison. Thats a commercial printer mounted to a back pack frame. Its actually a baby carrier frame. Cute petite skinny girl might actually fit in a back pack though. Like the follow up testing vid too. Still havent seen a control sample comparison.
      I admit Ive had to back up on vid several times due to not actually looking at the product /project in Naomi’s videos.

    1. why? It’s a simple calculation and as far as I understand it that happens in the firmware -> the GCode shouldn’t change from other printers, should it?

      Just read about that on the project page: He wants to put it in the firmware but doesn’t know where/how right now,

      1. GCode just says “go here this fast” and leaves the “how” up to the machine to figure out. Hence, you can theoretically use the same code on a cartesian or a delta machine (not accounting for printhead differences, etc).

        Our man in the OP got a tip on where to put the Z axis transfer function in Marlin so it’s good to go. Check his build log comments, pretty good stuff.

  2. Not sure how many will really need to backpack this around, but it has merit for mobile maker spaces, giving them the ability to transport more printers to a location, thereby serving more makers.

  3. This is a nice project and good implementation. I have been working on this principle since 2014 (mainly for resin 3d printing, https://www.lumindustries.com/the-new-lumifold), and got a patent for this system for my startup (I am the designer/developer/firmware writer/tester). Currently I have a prototype working quite well, not yet on the market anyway. And yes, the Z axis being non linear is a bit difficult, especially if the machine is super compact so you have very tight spaces for encoders or sensors. And with resin, tolreances are even smaller.

    1. Even if you don’t find that useful (I’m sure many will) it is still a boon for small workshops – set it up when you need it have it filling less volume when you don’t.

      Quite like the concept and execution – take a few more iterations on the design to really appeal though – a bigger build volume even if its only x-y would help. (Who doesn’t run into the limits) – but with x-y being the ‘strong’ direction for 3d printer layers parts tend to get laid that way, so as much size as could be squeezed out of it. Though I don’t know where you would get much back without making the footprint bigger it already looks pretty well optimized for that.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.