I’ve just built a Ratrig V-Core 500 and put an Enraged Rabbit Carrot Feeder on Top as well as a Filament Box for storing 9 Rolls. Since The Puffer Solutions Available absolutely don’t work with such a long Bowden System, i came to the conclusion i Need an electric rewinder. Designing the Hardware wasn’t that much of a problem, i stayed close to Bambus AMS, just more Lightweight, more generic and more Compact. After trying to wrap my head around the speed range problem (a nearly empty spool needs more revolutions), i came to the conclusion that i could just move the motor too fast and let it slip. I will need to try to know.
I have some basic Python skills, and tried to find the right spot to insert the code for activating the motor (simple DC Motor 3-6V). after searching in the ercf.py, i wasn’t any smarter afterwards, it often seems to refer to variables and functions in klipper. The Klipper Code is even more complex. I really need some help implementing this.
So Basically i want to use the Raspberry Pi GPIO pins to control a transistor circiut that can move any motor in both directions. I have 18 GPIO Pins Available, so 2 for each motor, 1 for each motor direction. The Gearing is Basically the Same as Bambu uses it, so it releases the active rolling shaft by turning into the opposite direction (First Stage Feeder Rebuilt )
Please refer to the Added pics to see what i have in mind. some details as the motor cages still need to be drawn, but i think you get the basic idea.
I have made a custom PCB based on sx1509 and a bunch of DRV8833s and implemented the control logic in Happy Hare. The solution works, and I have tested the rewinders up to ~3K cycles. But, the chewap motor gear box that I was using start to bind after that many cycles (though still usable). The motor also makes a ton of noise during loading/unloading.
I’m looking forward to the Motors and bearings too arrive, then i’ll test the mechanism manually. Noise and weardown wasn’t on my radar till now. i assume the weardown isn’t that much of a problem since i wanna print the gears. easy and cheap to replace.
the I2C controller solution is definitly worth a thought, though i’m not sure if i need a slow decay, and definitly not a coast mode, since the drive shaft gets released after unloading. i’ve observed the behaviour of my bambu AMS for a while, and although every motor has a separate PCB on it, it always seem to spin at the same speed.
You may have a github repo or anything else where you store your happyhare fork? is it even a fork?
i’m also quite curious of how you implemented this mechanically.
The passive rewinder you’re using now also looks clever, but also quite spacy. But it seems like the best solution if my plan fails somehow.
I had to code some custom logic for controlling the DRV8833, but yes, I used slow decay in most of the operations. I also tried a “forward stall” idea where during printing the stepper moves in fast decay, but in a tiny current that it is stalled in the direction of extrusion, to help the extruder grip the filament from the spool. The idea works, but the small current PWM generates a high pitch noise that I don’t like.
It’s not a fork but a klipper extension and some Python magic to hijack into HHv2. It worked fairly well for my experiments’ concern, but again, I didn’t quite like the noise so the five rewinders are still sitting idle in my room…
Mechanical wise it’s just a stupid setup: a roller with hooked to a DC motor, just that. I took care to choose a DC motor that is just strong/fast enough that can overdrive enough filament during rewinding and rely on rim slip when the spool is full; it’s also weak enough that won’t cause any trouble during printing: the toolhead extruder is ok with the motor’s internal friction, and the back EMF doesn’t fry the motor drivers.
I can share my code but it’s pretty specific to the I2C+DRV8833 setup so you’d probably also want my stupid PCB (schematics, since I don’t have more spares at the moment). You will need to compile my modified klipper firmware for this to work, so kind of PITA. I had two threads discussing what kind of modification was required on this forum, so you can check that as well.
The passive rewinder works well and it doesn’t take that much space. It’s about 40mm-ish taller than my motorized rewinder, but will fit in those food dry boxes people use for storing filament, I think.
i’d be more than happy to get just some hints:
-i assume i need to implement this in python, although jinja would be the smooth way
-i’m also happy with using the Raspberry GPIO as another mcu
so:
i need a variable that activates the motor. which motor is logical, i’ll just use the active Gate to determine that with conditionals.
but what should i use to start that? the encoder? or call a variable in the unload macro? thats where my mind is hanging.
and i’m not sure about the flow of execution. i think i can achieve that as a function, but where should i call it?
if thisiscam95 is the same as thisiscam on github, i found some forked codes. still i’m not convinced of the i2c solution. it has pros, like less cables. but cons, like needing to adapt the C firmware for the board, more complex updates…keep it simple…
i got all the parts here btw. start a testprint the next few days, coat the active roller with rubber spray, then i’ll test the motors and determine the resistor i need with a potentiometer to get the appropriate speed. as you said, pwm seems too noisy
You haven’t mentioned what’s the electronics for your motors? Are you using a DC motor driver? Or mosfets on a standard printer board?
If the later, you can’t control the direction of the motor (might be fine depending on what you want), but you can just use the motor as a generic_fan in klipper.
If the former, you’d might still need custom firmware for it work properly completely. I tried simply controlling the driver I had as two PWM pins in klipper. But that doesn’t quite work due to klipper timing — there can be abrupt unintended motor movements when the two pins changes are in transient.
i need a variable that activates the motor. which motor is logical, i’ll just use the active Gate to determine that with conditionals.
but what should i use to start that? the encoder? or call a variable in the unload macro? thats where my mind is hanging.
I monkey patched HHv2 to include those rewinder movements: https://github.com/thisiscam/happy_hare_motorized_rewinder/blob/main/mmu_rewinder_patch.py . You can either 1) fork HH 2) use the approach like in my monkeypatching 3) communicate with moggie (author of HH) to include proper hooks to run your rewinder. I’ve talked to moggie about 3) and he is quite open to this option, but I stopped chasing the rewinder project, as I’ve mentioned above.
You will likely need the rollers to slip on a spool — make sure the rubber spray is not too much. I have found plain ABS printed rollers to work very reliably on cardboard spools.
You probably don’t want to use a resistor as a voltage divider to control the speed of the motor. A better option is to get a buck converter with adjustable voltage, and use that to power all your DC motors.
That’s probably the second worst way to do it (the first is using a rheostat like @ac1dwalk3r was thinking about).
Ideally, you want a PWM signal to control the speed of the DC motor. Along with that, you want to have an H-Bridge to control the direction of the motor.
If you’re looking for a quick and dirty approach to this, start with GPIO 18 on the Raspberry Pi 40 pin header - this is the “PCM_CLK” pin and can be used to generate a PWM output without any software overhead. I believe there other pins that provide this function on different Raspberry Pis, but GPIO 18 should be able to provide a hardware generated PWM signal on any of them.
Next, you need an H-Bridge driver, @thisiscam95 hasn’t really given concrete specifications for what he wants, but something like the L293(D) should be a good starting place (reasonable current, cheap, easy to find and very robust):
With this solution, the PWM output of the Raspberry Pi will have to be redriven but buffer chips are also very cheap and easy to work with.
I thought about DRV8871 H-Bridge drivers, they can use PWM, but you can also just solder a resistor in and use boolean signals. And it can drive the motor in both directions. Alternatively, i could make my own circuit board with a few mosfets or optocouplers.
About the rubber rollers- i’ll need to try. Alternatively we have an old makerbot with dualextruders at my university, may TPU Coated ABS Rollers work better, or just ABS(if this is reliable with plastic spools too)
Edit: i just noticed i may could use an RP2040 plus as mcu expansion, that may could prevent me from manipulating the Klipper C source code? I really need to read your code, i’m just guessing at the moment
PWM seems too noisy, not sure if i should use this approach. But i figured it could save me some pins. 9 boolean outputs to determine which motor, 2 pwm signals to determine speed and direction
The driver you linked seems like a good solution if i opt to make my own circuit board. Alternatively, id use drv8871 H-Bridge drivers
Just refering to thisiscam95’s experience.
But step by step, first i’ll need some printing, then i’ll need some mechanical testing, then i’ll need to check thisiscam’s code, then i can decide what is the optimal way to control the motors.
@thisiscam95 hasn’t really given concrete specifications for what he wants
I already have a working motorized rewinder setup using DRV8833s. I was just giving my suggestions to @ac1dwalk3r about his potential setup…
That’s probably the second worst way to do it
@ac1dwalk3r will need some kind of power source for his motors. I’m not sure what motors he/she have in mind, but usually for rewinders, these are <12V motors, and one will either need a buck converter or a separate power supply. An adjustable buck converter is easier IMO, and one can turn down the (fixed) speed and torque by turning down the voltage.
Of course, one will also need some circuitry to drive the motors, be it mosfets or H-bridge drivers, depending whether one wants to control the direction. If speed control is necessary, then PWM would be necessary, at the cost of motor whining at low speeds.
While that is true, in practice, there are bunch of audible frequencies generated by the rotor even at high PWM frequencies and will whine my head out.
This noise is especially prominent if the motor is kept not rotating (motor stalled) — I was experimenting with an idea to let the motor stalled by a small current, to free the extruder from the internal friction of the rewinder motor, during printing. While the idea works out, the PWM noise was unbearable so I gave up on this idea.
In implementing the DRV8833 with Klipper’s C source code, modifications were necessary due to its motor driving requirements. A key issue to consider is Klipper’s inability to alter two output pins (whether PWM or not) at the same time, to my knowledge.
For the DRV8833, simultaneous control of two PWMs is essential for managing speed, direction, and decay mode. Transitioning between movements requires careful synchronization; if one pin is modified before the other, it leads to a brief transient state. During this state, the motor may operate in an unintended mode, causing abrupt movement.
This issue may not be present with other DC motor drivers. Based on your description, using the DRV8871 might offer a workaround. With it, you could deactivate the motor, adjust the PWM/decay mode, and then reactivate it. This process should be manageable via standard gcode or Python and circumvents the need for simultaneous pin control.
I’m not disagreeing that they will require a power supply but “an adjustable buck” really isn’t what you’re implying. There are three issues that I can see right off the bat:
Buck topology will never go down to 0% power. Depending on the flyback diode in the circuit, you won’t be able to go below 0.5V and it’s generally 1.25V for most circuits. You can shut it down but that adds cost and complexity.
How do you specify the voltage output electronically? I’m guessing you’re thinking of something like a digital pot on the feedback circuit but this needs to be properly sourced, simulated and tested. Regardless, you’re going have the issues noted in point 1.
When you’re specifying the coil for a buck converter, it should be done for a single voltage output. You can get away with a single one for a fairly wide range of output voltages but when you start getting lower, the efficiency drops 'way down and you’ll start seeing noise on the output.
I’ve done a lot of DC motor PWM circuits over the years and never had an issue with noise. I’ve helped people who have had issues with noise and it has always come down to them not understanding how to select the proper clock for the PWM in terms of the number of bits resolution.
Regardless, my suggestion for using the PWM generated by the rPi and using the L293Ds was to provide @ac1dwalk3r with the simplest/cheapest approach to start with. They haven’t provided enough information regarding the motors and current they want to use to do anything more than that.
Just for clarification:
Mechanical Setup:
2 3030 Extrusions as Frame (And a Box with lots of silica around it)
3D-Printed Spacers to hold bearings and axels
693ZZ Bearings, with 3mm Steel Rods, that Hold 3D Printed Rollers
R280 DC Motoren 3-6V - Cheap, may they work, may they don’t.
the gearing from the Bambu First stage Feeder rebuild->printables.com (the only reason i need to change direction)
Electronics:
Maybe a RP2040 Plus board as mcu
Either PWM Motor Drivers (DRV8871 won’t work i figured out. wrong Voltage range)
Or Buck Converters(I like that Idea) - But since we have 3 Brains here, one telling PWM is doable without noise, i may should give it a try.
Well, thanks to thisiscam, i got some code. It definitly needs some adaptions, but its a start, i appreciate that.
I really don’t wanna rush the electronics decision, there are many ways to do that and many things to keep in mind. All in all i think its a good idea too keep it simple enough to enable others to rebuild it. There’s a big difference between a non Programmer, a Programmer and a good Programmer.
Btw, my Name is Sebastian. I’m a He, since i’ve read some unsure therms
I’ve spent quite a bit of time over the past few months getting the rewinder to work, so I thought I’d share my findings.
Choosing the DRV8833 was mainly about cost-effectiveness and compatibility with the N20 motors (6V, 500 RPM) I was using.
Alternate motor drivers like L298n or TB6612 should work too, for the motors we are dealing with.
If you just want single direction, you can get a bunch of mosfet and use those too.
In any case, you’d need a power source, likely a buck converter for convenience.
A quality R280 motor could work with appropriate gearing. However, it would require a printed gearbox, like your design suggests, whereas the N20 motors I got come with built-in metal gears. After doing the math, I found that the N20 was the most affordable option that could just about meet the requirements for rotating a spool fast enough with varying filament diameters. I have Python code that calculates the required torque and speed for varying filament amount on the spool — let me know if you’d be interested in that.
However, from my experience, the ideal motor would probably be a 370 motor with built-in gear reduction to around 600 RPM, with a roller diameter of about 26mm to 30mm. These are available on AliExpress at a slightly higher cost than N20 or R280. I ordered a couple but didn’t continue with the project.
My main concern with the 370 motor is its potential to add too much drag during printing. But I think it should work well with a strong enough extruder, or by using the ERCF gear sync option in HH.
I really don’t wanna rush the electronics decision, there are many ways to do that and many things to keep in mind. All in all i think its a good idea too keep it simple enough to enable others to rebuild it.
I totally agree with the keeping it simple. The problem is, you will soon find the complexity of circuitry come to bite you when you want to wire up 12+ rewinders… The sole reason I went with a custom PCB is to avoid all the craziness of having to solder all the drivers and the SX1509 with bare wires — same story for RP2040 if you plan to use that. The PCB I got allows me to connect 8 rewinders per board and dasiy chain up to 32 rewinders – which should be plenty by today’s MMU standard. What I’m saying is: You might end up wanting to design a similar PCB, even just for the fact that you want it to be buildable by someone else. Since it’s all breakout boards, one can order such PCB real cheap.
