Nice to see this sort of R&D. I'd like to suggest using a custom tapered socket and pull studs of the style used on most machine tools. A pull stud would allow the motor to be replaced with a lighter air cylinder. Tapers accurately position tooling axially and radially.
so now that i know a bit more about how these magical trinamic drivers work, it just reports when the motor stalls right? so what do you do when that happens? Do you just make the motor stop? In that case, how would locking the tool in place work? I get that it would rotate until it stalls, but my concern is that with your system you dont have any spring force, so i can see a scenario where the motor rotates and stalls, but then when the motor locks into place the motor goes back a step, and now there's a fraction of a millimeter in which the head can wobble around. Are you concerned about this at all? Edit: great work of course :)
Yup, that's exactly it. The lock twists until the stall detection signal triggers or the motor goes through a set number of steps. (There's some debouncing at the beginning when the motor first starts moving too.) It's hard to see, but there is actually spring force in the 3D-printed wedge-lock. twisting the lock into the wedge until it stalls actually deforms the wedge-ever-so-slightly. My take on how the stall-detection signal fires is that it trips when a motor cannot continue stepping, so it doesn't actually slip back a step. I'm making this assumption since one of the suggested applications is as a limit-switch replacement, which is actually what the Prusa Mk3 does. I need some more tests, but if it turns out that I actually am losing a step, I can replace the cable with something "springier" like nylon fishing line such that there still exists some preload over a longer distance.
I like it. But please consider to dump smoothieware and swap to reprap-firmware. I don't say go DUET (but you really should) but smoothieware lacks so much features you get for free with reprap-firmware, that it isn't fun anymore. I say this out of a personal experience, I was there almost 3 years ago, with my version of a toolchanger. RRF removes so much pain I had with smoothieware...
This is a good insight. Right now, I've somewhat abstracted it out so that I can just test the hardware by writing this command-line interface wrapper over the board. I admit that I'm fairly new to the homebrew 3D printer scene, so I started with a board that seemed to have a stable architecture to develop on. I may switch to a Duet or Marlin in the future once I go through more hardware tests (and once I can justify buying yet another 3D printer controller). I really appreciate the context.
Joshua Vasquez look at Klipper. It uses a raspberry pi for the motion planning and just about any 8bit control board for the actual motion control. You can even use multiple control boards. Next to the duet, it’s probably one of the best ways to get as many extruders as possible. It’s fairly young, but already pretty powerful and being developed more rapidly than other firmwares, IMHO.
@@POOFjunior if you feel good in python, you should definitely look in the direction of the Klipper. It would be great to have a tool changer function in Klipper firmware.
Joshua Vasquez I'm with Rene on the Duet/Smoothieboard. I went Smoothieware and hit a wall. The open source from E3D will surely be RepRap or a derivative to simplify this in the upcoming months That's just my take....
I am in progress on a kinematically-coupled Zaxis now. Most of my unpolished bleeding-edge progress is on Twitter, but I will be sharing more infonin the next month. Thanks for checking in!
Can you share firmware? I understand knematics but didn't figure it out firmware slicer setting. I want to build it but firmare scares me. Can you explain firmware please please please.
With my newest version using the Duet, there's actually no firmware changes. Everything is handled by scripts that live locally on the SD card. github.com/Poofjunior/jubilee_configs
In this example I was using a Smoothie Board with some crudely hacked firmware, but these days, I've switched to a Duet2 running RepRapFirmware with a set of custom macro files. All those files are up for grabs here: github.com/machineagency/jubilee/tree/master/software/duet_config_files/duet2
I love to watch your progress! It's just wow!
I love this project. You are doing some great work.
This looks amazing! whoa!
Awesome work!
Nice to see this sort of R&D. I'd like to suggest using a custom tapered socket and pull studs of the style used on most machine tools. A pull stud would allow the motor to be replaced with a lighter air cylinder. Tapers accurately position tooling axially and radially.
Fantastic... great work !
Great work
Hello Joshua, great videos. Had a question, why didn't you take the Corexy process? Do you have any experience with printing?
greeting
Excellent work. But this cannot be used with the Repetier Host Software? for 3D printers
Thats a Very Nice project Sr! Congratulations on that. Is It possible to share all your cad design and project so I can try make one on my own?
Great Work! Are you happy with the Carbon Fiber X Gantry which is milled from a plate? Or would you recommend a 4 quare tube instead? :)
Awesome!
so now that i know a bit more about how these magical trinamic drivers work, it just reports when the motor stalls right? so what do you do when that happens? Do you just make the motor stop? In that case, how would locking the tool in place work? I get that it would rotate until it stalls, but my concern is that with your system you dont have any spring force, so i can see a scenario where the motor rotates and stalls, but then when the motor locks into place the motor goes back a step, and now there's a fraction of a millimeter in which the head can wobble around. Are you concerned about this at all?
Edit: great work of course :)
Yup, that's exactly it. The lock twists until the stall detection signal triggers or the motor goes through a set number of steps. (There's some debouncing at the beginning when the motor first starts moving too.) It's hard to see, but there is actually spring force in the 3D-printed wedge-lock. twisting the lock into the wedge until it stalls actually deforms the wedge-ever-so-slightly. My take on how the stall-detection signal fires is that it trips when a motor cannot continue stepping, so it doesn't actually slip back a step. I'm making this assumption since one of the suggested applications is as a limit-switch replacement, which is actually what the Prusa Mk3 does. I need some more tests, but if it turns out that I actually am losing a step, I can replace the cable with something "springier" like nylon fishing line such that there still exists some preload over a longer distance.
I like it. But please consider to dump smoothieware and swap to reprap-firmware. I don't say go DUET (but you really should) but smoothieware lacks so much features you get for free with reprap-firmware, that it isn't fun anymore. I say this out of a personal experience, I was there almost 3 years ago, with my version of a toolchanger. RRF removes so much pain I had with smoothieware...
This is a good insight. Right now, I've somewhat abstracted it out so that I can just test the hardware by writing this command-line interface wrapper over the board. I admit that I'm fairly new to the homebrew 3D printer scene, so I started with a board that seemed to have a stable architecture to develop on. I may switch to a Duet or Marlin in the future once I go through more hardware tests (and once I can justify buying yet another 3D printer controller). I really appreciate the context.
Joshua Vasquez look at Klipper. It uses a raspberry pi for the motion planning and just about any 8bit control board for the actual motion control. You can even use multiple control boards. Next to the duet, it’s probably one of the best ways to get as many extruders as possible. It’s fairly young, but already pretty powerful and being developed more rapidly than other firmwares, IMHO.
@@POOFjunior if you feel good in python, you should definitely look in the direction of the Klipper. It would be great to have a tool changer function in Klipper firmware.
@@scottjackson2812thanks for the heads-up. It looks like I'm going to start porting most of this stuff over in that direction in the next few months.
Joshua Vasquez I'm with Rene on the Duet/Smoothieboard. I went Smoothieware and hit a wall. The open source from E3D will surely be RepRap or a derivative to simplify this in the upcoming months That's just my take....
Do you have anymore info on the printer you are putting this on?
I am in progress on a kinematically-coupled Zaxis now. Most of my unpolished bleeding-edge progress is on Twitter, but I will be sharing more infonin the next month. Thanks for checking in!
Can you share firmware? I understand knematics but didn't figure it out firmware slicer setting. I want to build it but firmare scares me. Can you explain firmware please please please.
With my newest version using the Duet, there's actually no firmware changes. Everything is handled by scripts that live locally on the SD card.
github.com/Poofjunior/jubilee_configs
Wich firmware do you use to change tool? Or Wich can I use for that?
In this example I was using a Smoothie Board with some crudely hacked firmware, but these days, I've switched to a Duet2 running RepRapFirmware with a set of custom macro files. All those files are up for grabs here:
github.com/machineagency/jubilee/tree/master/software/duet_config_files/duet2
Hello is this nice machine for sale?
the download link BROKEN please re upload THANKS.