Correct, I've seen that, however this would not really be a meaningful configuration, from my point of view. It makes sense if an additional reduction is installed in addition to the existing pulley. Here, original one is removed and there is just a single GT2 gear present, which has 25 teeth. So which ratio would that be? The one comparing old and new? Would you use gear-ratio when replacing the pulley?
@CasualCNC i would use the ratio that the planetary gearbox gives, and set the rotation distance to the number of output teeth x 2 of the belt. Its always best to calculate instead of guess xD I love the printer tho
@@SlinkySlonkyWaffle I see, you are absolutely right! Somehow I thought you are suggesting leaving the original rotation_distance and adding ratio to that. So "rotatoin_distance=50" and "gear_ratio=5:1" should work just fine.
z-hop is enabled with slope, 0.4mm and 1500mm/s². The printer had around 4-5 hours of printing since installing the reduction gear. No idea what realistic longevity to expect.
you can calculate for the resistive force of the friction and increase it to be at least the same or slightly higher than the force of your whole gantry/assembly pushing down
then the whole system will be statically balanced, but you achieved it either way, if you want to not have any excess resistance you can do it the way I said it, or if anyone else has this problem
Did you consider a counterweight like on the Voron Switchwire? I am facing similar challenges, and would love to hear your reasoning. Also, you have introduced misalignment so the belt is no longer running straight where it should be. Se at 3:21. The belt it not perpendicular to the movement of the gantry, which will mess with the travel accuracy. Also, just by looking at the printed gears, it is obvious that this is gears that are really loose on tolerances. Which again, hurts accuracy. There has been quite a lot of noise about that for BMG style extruders lately. There have though, been no such focus on steppers driving belts nor on idlers. I love your focus on back clash, and it would be great to get some feedback on how this worked out for you. I just don't know what test ask you to do, since accuracy on the Z, I am not really sure how to test for that. I guess solutions like this probably is good enough for a ton of users, as their prints are not that picky on dimensional accuracy. Good enough, is good enough. Thanks for showing us the weight on the Z. That was way heavier than I expected. As much as I love this design, it is done the wrong way for cross gantry. The weight of the Z, is just way too heavy. Also, as much as love the innovative form of this, it seemingly offers no way to calibrate the axis, as to get them square. Did I miss something here? The accuracy of frame alignment is bound by the printed parts, like the top and bottom? Is there more to it? You got 3 rails running in parallel. Usually that is pretty tricky to align. There is way more slack in these rails than people think, so if this just snapped into place, and the printer accuracy was enough for rails alone? I would love to hear from you on that one. Despite all these issues that seemingly should result in sloppy tolerances, I am continuously amazed that in the end, the printer accuracy is way tighter than it "should" be. Again, I really like this design. Just wondering how this worked out for you.
Interesting printer design! Do you have to calibrate and compensate for when the print head is all the way out on the cantilever arms? I imagine that there has to be some amount of deflection happening. Or is it linear and is compensated for just by tramming the bed? Even so, I imagine this could cause print skew, which I think printing software can compensate for, have you investigated this?
It is compensated by bed mesh leveling within software only, klipper at the moment. The range is however surprisingly small being within 1mm. See my video "Second Iteration of Experimental Crossed Cantilever 3D Printer: N3D" and comments there for more information.
Im curious how backlash will affect this. If it's small enough, might just do it! I always do belted z and have found in spite of the z axis weight, backlash still matters. I use a belted reducer with a 16t gear on the belt and a big 3d printed 80t gear on the other, then a 20t pulley for the belt attached to the axis. Belts reduce, but sont eliminate, backlash. I saw one video where someone made the "ultimate" belted z and had 2 reducers and some gears. Needless to say, didn't go well.
I've just printed a "Simple Z banding/wobble test tower" available from TeachingTech on printables.com, here is the result: www.printables.com/model/393668-simple-z-bandingwobble-test-tower/comments/2196999 As far as I can judge, I see no z-axis based issues. Height of first layer was badly calibrated, so artifacts visible there. However, my first assembly had a problem with backlash because gears where pressed too tight in one direction. Z-axis was not going down on its own without sun-gears installed. Adding some washers at one place solved the problem and now a minimal drop is also visible when steppers are disabled. This tiny drop on power-off could probably be a definitive test if system is working fine. Also, minimal z-movements are visible when printing due to mesh bed leveling.
Backlash should not matter as Z-Axis is constantly pre-loaded in one direction. It could be an issue, if weight is too small (but then you don't need it) or KeyBak or similar is used in combination (which you probably wouldn't anyway) or z-axis acceleration is very high (which normally isn't). I haven't noticed any print artifacts on a test run, but will keep an eye on that.
There is another thing you should watch out: If friction of planetary gears gets too high due to material used or printer setup. A good test would be to remove the sun-gear and test if z-axis goes down. Expected: It should go down!
@@gargert1433 It is an additional friction from planetary box itself plus a higher necessary rotation for the stepper motor, so it's static friction has increased by the factor of 2.6: 10 mm/rotation (now) instead of 26 mm/rotation (earlier).
You've got the right idea but you're thinking backwards. When driven from the stepper side, the z is lighter yes. But for the z to drive the motor thru the planetary, it actually takes more force because when z is driving the stepper the output of the planetary becomes the input so the gear reduction works backwards.
Hmm... there must be a misunderstanding. The whole purpose of installing it, was to increase the force necessary to move z-axis/gantry down by gravity so it does not move (or at least moves slower). In my opinion, this is also exactly what I've stated. My original design used 16 teeth (32mm/rotation) pulley, then I switched to 13 teeth (26 mm/rotation) pulley, which should have increased necessary force (to move it down by gravity) by the factor of 32/26 = 1.23, which did not help much. Installing this reduction gear increased it further by the factor of 26/10=2.6. Plus the friction of the reduction gear itself, which is significant, and the goal achieved!
in klipper, you can put in a "gear ratio" for any particular stepper, instead of changing the rotation distance
Correct, I've seen that, however this would not really be a meaningful configuration, from my point of view. It makes sense if an additional reduction is installed in addition to the existing pulley. Here, original one is removed and there is just a single GT2 gear present, which has 25 teeth. So which ratio would that be? The one comparing old and new? Would you use gear-ratio when replacing the pulley?
@CasualCNC i would use the ratio that the planetary gearbox gives, and set the rotation distance to the number of output teeth x 2 of the belt. Its always best to calculate instead of guess xD
I love the printer tho
@@SlinkySlonkyWaffle I see, you are absolutely right! Somehow I thought you are suggesting leaving the original rotation_distance and adding ratio to that.
So "rotatoin_distance=50" and "gear_ratio=5:1" should work just fine.
@CasualCNC test it and see if it works, double check the klipper config reference and double check the math!
Это просто потрясающе, у меня нет слов, всё просто и компактно
Short, sweet, and to the point! I like it! Great solution!
Very nice solution, keep it up!
Awesome project, can't wait to build one 😢
Wow, I really wanna build a 3D printer like this, looks very neat 👌
Выглядит просто, это большой плюс. Уважение)
Thanks for showing and sharing!! Have a awesome day 😎😎‼️‼️
I love this channel. Such fun concepts to explore. Keep it up 😄
Looks great!
"no z-hopping allowed machine"
z-hop is enabled with slope, 0.4mm and 1500mm/s². The printer had around 4-5 hours of printing since installing the reduction gear. No idea what realistic longevity to expect.
Way more affordable than G2Z drives, I might use these on a Micron or similar build.
Nice design!
great design and video
you can calculate for the resistive force of the friction and increase it to be at least the same or slightly higher than the force of your whole gantry/assembly pushing down
then the whole system will be statically balanced, but you achieved it either way, if you want to not have any excess resistance you can do it the way I said it, or if anyone else has this problem
Did you consider a counterweight like on the Voron Switchwire? I am facing similar challenges, and would love to hear your reasoning.
Also, you have introduced misalignment so the belt is no longer running straight where it should be. Se at 3:21. The belt it not perpendicular to the movement of the gantry, which will mess with the travel accuracy.
Also, just by looking at the printed gears, it is obvious that this is gears that are really loose on tolerances. Which again, hurts accuracy. There has been quite a lot of noise about that for BMG style extruders lately. There have though, been no such focus on steppers driving belts nor on idlers. I love your focus on back clash, and it would be great to get some feedback on how this worked out for you. I just don't know what test ask you to do, since accuracy on the Z, I am not really sure how to test for that. I guess solutions like this probably is good enough for a ton of users, as their prints are not that picky on dimensional accuracy. Good enough, is good enough.
Thanks for showing us the weight on the Z. That was way heavier than I expected. As much as I love this design, it is done the wrong way for cross gantry. The weight of the Z, is just way too heavy.
Also, as much as love the innovative form of this, it seemingly offers no way to calibrate the axis, as to get them square. Did I miss something here? The accuracy of frame alignment is bound by the printed parts, like the top and bottom? Is there more to it?
You got 3 rails running in parallel. Usually that is pretty tricky to align. There is way more slack in these rails than people think, so if this just snapped into place, and the printer accuracy was enough for rails alone? I would love to hear from you on that one.
Despite all these issues that seemingly should result in sloppy tolerances, I am continuously amazed that in the end, the printer accuracy is way tighter than it "should" be.
Again, I really like this design. Just wondering how this worked out for you.
Look very similar to a planetary extruder like the orbiter without a special the shaft. Maybe a cool design for an new extruder
Amazing!
Why not have a vertically stationary gantry and let the bed move up and down
Interesting printer design! Do you have to calibrate and compensate for when the print head is all the way out on the cantilever arms? I imagine that there has to be some amount of deflection happening. Or is it linear and is compensated for just by tramming the bed? Even so, I imagine this could cause print skew, which I think printing software can compensate for, have you investigated this?
It is compensated by bed mesh leveling within software only, klipper at the moment. The range is however surprisingly small being within 1mm. See my video "Second Iteration of Experimental Crossed Cantilever 3D Printer: N3D" and comments there for more information.
use constant springs to hold your Z weight.
Cool!
Im curious how backlash will affect this. If it's small enough, might just do it! I always do belted z and have found in spite of the z axis weight, backlash still matters. I use a belted reducer with a 16t gear on the belt and a big 3d printed 80t gear on the other, then a 20t pulley for the belt attached to the axis.
Belts reduce, but sont eliminate, backlash. I saw one video where someone made the "ultimate" belted z and had 2 reducers and some gears. Needless to say, didn't go well.
I've just printed a "Simple Z banding/wobble test tower" available from TeachingTech on printables.com, here is the result:
www.printables.com/model/393668-simple-z-bandingwobble-test-tower/comments/2196999
As far as I can judge, I see no z-axis based issues. Height of first layer was badly calibrated, so artifacts visible there.
However, my first assembly had a problem with backlash because gears where pressed too tight in one direction. Z-axis was not going down on its own without sun-gears installed. Adding some washers at one place solved the problem and now a minimal drop is also visible when steppers are disabled. This tiny drop on power-off could probably be a definitive test if system is working fine.
Also, minimal z-movements are visible when printing due to mesh bed leveling.
EPIC
will you be posting the actual CAD for it? I would love to adapt to a project I am working on
Original design exported as a STEP file and uploaded. I would be glad to hear any feedback you may have.
@@CasualCNC very excited for that thank you so much !
What about backlash compensation from the planetery gears?
Backlash should not matter as Z-Axis is constantly pre-loaded in one direction. It could be an issue, if weight is too small (but then you don't need it) or KeyBak or similar is used in combination (which you probably wouldn't anyway) or z-axis acceleration is very high (which normally isn't).
I haven't noticed any print artifacts on a test run, but will keep an eye on that.
There is another thing you should watch out: If friction of planetary gears gets too high due to material used or printer setup.
A good test would be to remove the sun-gear and test if z-axis goes down. Expected: It should go down!
Constant force spring?
That could be even better solution, if implemented right.
Does it not drop just by the printer head being 5 times lighter from the motors perspective?
See video at 0:10, that's what happens to z-axis which weights 1.8 kg when two NEMA 17 stepper motors lose power.
@@CasualCNC well yes I understand that, once you install the planetary gears, what's keeping the head from falling?
@@gargert1433 It is an additional friction from planetary box itself plus a higher necessary rotation for the stepper motor, so it's static friction has increased by the factor of 2.6: 10 mm/rotation (now) instead of 26 mm/rotation (earlier).
You've got the right idea but you're thinking backwards. When driven from the stepper side, the z is lighter yes. But for the z to drive the motor thru the planetary, it actually takes more force because when z is driving the stepper the output of the planetary becomes the input so the gear reduction works backwards.
Hmm... there must be a misunderstanding. The whole purpose of installing it, was to increase the force necessary to move z-axis/gantry down by gravity so it does not move (or at least moves slower). In my opinion, this is also exactly what I've stated.
My original design used 16 teeth (32mm/rotation) pulley, then I switched to 13 teeth (26 mm/rotation) pulley, which should have increased necessary force (to move it down by gravity) by the factor of 32/26 = 1.23, which did not help much.
Installing this reduction gear increased it further by the factor of 26/10=2.6.
Plus the friction of the reduction gear itself, which is significant, and the goal achieved!
woah, is this a cantilever corexy!?
That's a cartesian, see ua-cam.com/video/bA-R3nCNyYw/v-deo.html
Put two of these on a Voron Switchwire and you won't need the keyback.
I'm afraid this won't work with CoreXZ design due to backlash.