Appreciate the efforts of the conductor of this community who was @ThantiK during those past nice years of us communicating to each other here.
We are about to develop a conductor software to make an open source multi-gantry 3D printer similar to AutoDesk escher. I kindly ask the software heads to give at least ideas and recomendations on writing such a software piece before G+ gets shut down. You do not have to participate with your precious private time but at least please give some tips and hints for the ones who want to work on this.
https://www.youtube.com/watch?v=z_yIn8V3UcU
You’ll want the bed stationary, except in the Z axis, I suspect. My first attempt would be a single shared rail for the X axis, with overlap in the travel for each head. You’re going to need to be able to center the nozzles on the travel line.
“center the nozzles on the travel line” is the hardest job I see besides programming the conductor. I agree. The common bed for all gantries simplifies the first iteration and allows using them as tool changers. Let’s keep the hardware in budget of $800 for the begining, please
@shauki Your ‘conductor’ is going to have to be at the slicer level. It’s the only thing that can determine which print head will be at what position and when. So you’ll need a rudimentary slicer software to start off with.
In fact, hand-coding the first bits of gcode may be your best option. Yeesh, this is going to need firmware too…
Actually, Klipper may be worth using here.
@Arthur_Wolf has kindly shared this link (catch before it goes away) https://github.com/Autodesk/machine-collaboration-utility/wiki/00---Intro
@shauki after reading this, exactly what I thought the machine setup should be is how they do it. continuous X gantry, with isolated X/Y with different firmwares running each head. Sweet that they can do it directly from Netfabb though!
If we call X as the direction of the common rail on the frame for all gantries, then collision avoidance has to be managed only in X direction. Z is common. Y travel of the tool takes place on the gantry in Y direction and not subject to collision avoidance, because X distance is the guard
Arthur writes “This was their early work, when they got it to work well they started working within their closed-source”
8.1. Note: The “Conductor” and “Player” MCU instances are independent from Netfabb
From https://github.com/Autodesk/machine-collaboration-utility/blob/master/documentation/FRD_Documents/1601123_Design%20Supplement_REV1.1.pdf
@ThantiK Hi, yes, I picked up Klipper last week and haven’t had time to load and run it. But it certainly allows the software to run on multiple CPUs.
I’m also building a multi gantry system, but my progress is dead slow.
@Arthur_Wolf wrote “(escher) it is the only software avalailable anywhere that does this”. I knoe Klipper needs OctoPrint which can talk to one brain only. If you know how to make Klipper talk to several brains then please share the knowledge.
@shauki Hi I am working on something very similar. I use 3 lead screws for Z. I’m using MGN7 rails which are perfect. I’ve set up PolyHeaded3D https://mewe.com/join/polyheaded3d on MeWe unless someone knows of another group.
@shauki Haven’t looked in detail, but AFAIK you use one controller (octoprint) and Klipper host on the same Pi talks to multiple distributed boards that are time syncd to a common clock. You can thus add any number of (arduino or STM32F1) to control your axes. The initial trick would be to split the G-code 1 layer at a time, and schedule it such that the gantries and print heads don’t collide.Later you could look at working on multiple layers simultaneously.
There’s a lot of mechanical work to be done to get the print heads and gantries smaller so they could be packed tighter.