RAMPSSB: Closed Loop DC servo drivers for RAMPS

Hey everyone!

So I've had it up and "finished" for a while now, but I figure I should probably get some feedback from the reprappers.

I've seen quite a few people working on "closed loop" 3D printer controllers, but most of them were never published, or had some really obscure BOM, and I had yet to find a sort of black box step/direction/enable --> closed loop quadrature DC motor controller available for purchase for a reasonable cost. I only use Cartesian ramps, so the DC servo motors would only be on the X and Y axes, and the Z and E axes can stay steppers, because there's really no reason to change that. So I made this board, which is an expansion board that slots over the X and Y stepper sockets on a RAMPS board and turns them into DC encoder motors. It can also be used with other systems as a 2-channel blackbox converter by just attaching the 5V, GND, STP, DIR, EN, Power and Enstop pins.

I used two Arduino Pro Micros as the processors, and stacked a L298N DC motor driver on top of the board as a driver. other than those two parts, its just the PCB, pin header, and the rest is optional. everything can be bought for about 20 bucks + the cost of the board, which is cheap from seeedstudio, but best bought in bulk

The final product is really bulky, and the firmware needs some work, but seems to behave correctly, and the hardware doesn't seem to have any issue. On the RAMPS side, this expansion board is treated just like a stepper motor.

More information and building instructions on the wiki: reprap.org/wiki/RAMPSSB
Source code and firmware on the Github: [github.com]

Does anyone here that knows more about control theory than I have any input or ideas on how I can make this system (specifically the firmware) better? Any suggestions?

IMHO, on a well built and dialed in printer the extruder motor is the weakest link. Even worse, when you beef up the X and Y axis to make people think, they can print faster then.
As long as the closed loop-algorhythm hasn't found a way into printer firmware it wouldn't make sense to use an external closed loop driver for extruders.

Cool solution. I agree with o_lampe -I think 'killer app' for the servo motor application would be extruder. Servo equipped extruder would allow for lighter effector/gantry and/or quicker retraction speeds. Even more interesting would be to track movement of the filament itself, not the motor, to eliminate elasticity/slip errors when feeding filament. Overall, I think we need a single servo version of the add-on, perhaps in pololu footprint so it's universal

Btw, do you move the motor every step received, aggregate x steps before movement or fit movement into time slots?

Edited 1 time(s). Last edit at 11/18/2017 01:10PM by newbob.

I was originally thinking of doing something for the extruder, but figured I would tackle the x and y first.

I hear you on the single. I've been thinking of doing a smaller one for single channel use.

My thought for an extruder is a DC gearmotor, but attaching the encoder to the filament. I'll see what I can whip up. Anything else that would be cool to see?

Is it really necessary to use two arduino Pro micros to control two dc-motors? How many I/O pins do you need for each encoder?
Is there an alternative for the L298N?

The killer isn't the IO pins, it's the number of Interrupts required and the processor speed.

Working at these speeds requires an interrupt on the Encoder channel 1 and channel 2 lines, the endstop, the step pin and maybe the direction pin. That's 5 interrupts, and the Pro Micro is the cheapest decent processor I can find (~$5) that has 4 interrupts. In theory I could go with a more expensive processor (like a Teensy) that can handle both channels, with all the inturrupts required, but why spend $30 for a processor when you can just buy 2 for $10 that get the job done. I've been using a 2000RPM 24V DC motor with a 2000 ct/rev encoder on it, and it hiccups a little bit at that speed with that many inturrupts, but with most simple 100 ct/rev motors it does just fine.

Same deal with the L298N. It's nice because it's mass produced to the point that it's dirt cheap and it works. Its a bit on the large side, but it can pump out 2 amps per channel, and I don't really see a reason to not use it.

It's also worth noting that I am going to see if I can crush the RAMPSSB down into a square the size of an L298N and make it a single channel version. I've got the board fired up, and hopefully I'll have that out in a bit.

Alright, done!

I smashed everything in the RAMPSSB into a small single channel board (StepServo) that fits under a L298N driver board and takes inputs from jumper wires. Seems kind of basic, but everything is there. The firmware is identical.




Github is here: [github.com]
Still have to do the Wiki

I've got parts on order to see if I can make a DC motor extruder with it. Stay tuned.

Why do you need an interupt on the endstop pin? The firmware takes care of the endstop and stops firing step pulses when hit. Adding a second control loop is redundant.
IMHO,the dir pin doesn't require an interupt neither.
Am I wrong?

ESP32 has two cores, can have one interrupt per core (I'm not sure if Arduino supports it) and costs $7:

[www.youtube.com]

I think a benefit of using single processor would be keeping relative movement of XY in sync.

@o_lampe

It's partly due to the coding method I use for the firmware. It needs to know where "0" is, in order to reset the encoder ticks to a known zero point. With some cleverer coding than what i'm doing, it may be be possible to do without the inturrupt on the endstop.

[github.com]

The Dir pin doesn't require an an endstop but it helps. The issue is that still puts us at 3 interrupts, which is above most ATMEGA328ps.

@newbob

Good call. Never occurred to me to use the ESP32 series. I figured anything with processor speeds that high would be out of budget, but it looks like you can get something nodeMCU-like for about 10 dollars, which isn't that bad at all.

You also make a good point about syncing. I thought about that, but I'm not sure if the RAMPS board does any syncing, or how it outputs it's step signals.

I've got a ESP32 on order to mess with. I'd say best case scenario it may be able to do both channels, and worst case scenario, its only 2 dollars more for a lot more processing speed, so it will definitely be able to destroy one channel and clean up these hiccups I'm having.

You mentioned you were having trouble with the firmware side of things. Have you seen this yet?

[github.com]

I wanna get this stuff going! I've finished up the parts for my micro extruder 2 and I'm hoping for something with more momentum than the tarroco drivers.

Here's the first version of the micro extruder in action:
https://www.youtube.com/watch?v=hAm5rLlzdFg

It worked okay but the encoder didn't have high enough ppr (12) and a 1000:1 geared motor would wear out too quickly with extruder speeds. Most only last a day or too... sigh.

The new design will be larger but uses a 4000 ppr encoder with a 150:1 geared motor with nylon gears to drive 2 hobbed gears to grip the filament on both sides. Its gonna be a beast.

Quote

Most only last a day or too... sigh.

I hear you... The only way to make this last is with brushless motors. Low kV pancake brushless outrunners to be exact.
Most of the RC-brushless stuff has no hall-position sensors. But equipped with sensors, there are no small enough controllers.

Quote
o_lampe
I hear you... The only way to make this last is with brushless motors. Low kV pancake brushless outrunners to be exact.
Most of the RC-brushless stuff has no hall-position sensors. But equipped with sensors, there are no small enough controllers.

My design doesn't need the encoder to be attached to the motor directly. So that isn't an issue. Are there no diy brushless drivers? Is that just a lot harder to do?

@warbunniex

Interesting. I went looking for something like this but didn't find it. I'll take a look and see if I can integrate it the software from that motor into the RAMPSSB system. They seem to know a lot more about control theory, but because they have to manufacture theirs its going to be harder to source. I'll take a look this weekend.

As for the DC extruder, I actually tried something similar, with the mindset that the extruder cant skip at very high speeds, so I used a massive motor with crazy 1:170 gearing. Surprisingly, i never stripped the filament, but the filament only got barely melted before being shoved out the nozzle, so it didn't behave like a liquid.



The way I did it was I put the encoder on the filament using printed parts and some orings, and it actually worked really well. I've been working the firmware to see if I can repurpose the endstop pin for telling the controller that the material is jammed or out if the motor is on and the encoder isn't moving. It wasn't perfect or even good, but it worked; I've got to tuned the motor to prevent overshoot. I just threw it up on a repo here:

Github for DC ServoStruder


@o_lampe

I cant find BLDC motor drivers that are both sensored and easily reversible. I work with some insane sized BLDC motors for industrial machines, but they dont really have open source drivers for BLDC motors that are easily arduino-able. China has even started to add insult to injury and sell 4000RPM BLDC motors in the NEMA 17 package, and I really want to use them, but there's not an easy way to do it.

NEMA17 BLDC ebay link

@warbunniex

Interesting. I went looking for something like this but didn't find it. I'll take a look and see if I can integrate it the software from that motor into the RAMPSSB system. They seem to know a lot more about control theory, but because they have to manufacture theirs its going to be harder to source. I'll take a look this weekend.

As for the DC extruder, I actually tried something similar, with the mindset that the extruder cant skip at very high speeds, so I used a massive motor with crazy 1:170 gearing. Surprisingly, i never stripped the filament, but the filament only got barely melted before being shoved out the nozzle, so it didn't behave like a liquid.



The way I did it was I put the encoder on the filament using printed parts and some orings, and it actually worked really well. I've been working the firmware to see if I can repurpose the endstop pin for telling the controller that the material is jammed or out if the motor is on and the encoder isn't moving. It wasn't perfect or even good, but it worked; I've got to tuned the motor to prevent overshoot. I just threw it up on a repo here:

Github for DC ServoStruder


@o_lampe

I cant find BLDC motor drivers that are both sensored and easily reversible. I work with some insane sized BLDC motors for industrial machines, but they dont really have open source drivers for BLDC motors that are easily arduino-able. China has even started to add insult to injury and sell 4000RPM BLDC motors in the NEMA 17 package, and I really want to use them, but there's not an easy way to do it.

NEMA17 BLDC ebay link

A BLDC in NEMA 17 size is way to powerful ( and heavy ) for an extruder.
The smallest sensored BLDC controllers I know are integrated in common brushless fans. I've built hundreds of BL outrunners from old CD.Rom drives and also later as a professional motor builder at Plettenberg-motoren.net.
There are pretty powerful fans out there. It would be interesting to see, if I could rewind them to lower kV and PWM control them by an Arduino.

Is it PWM control you are using to regulate the brushed motors?

BTW: Have you seen the video of my balancing bot with BLDC motors? It goes back and forth and stands still, just like we need for an extruder. But these gimbal motors are pretty weak.

Edited 1 time(s). Last edit at 04/18/2018 03:39AM by o_lampe.

@O_lampe

I was thinking of using the NEMA17 motor for the X and Y axes. I have bits of a machine that uses brushed 1250 rpm gearmotors, but I feel it could be faster, and brushes dont last forever.

Interesting. I'm using PWM and Direction pins for control output. if there's a control system that can take that input and use it to control BLDCs, it would be perfect. I've had the philosophy that mass produced is better than custom made (its cheaper and easier to get a hold of), but I'm not sure if there is such a thing that's mass produced.

at some point I'll get around to publishing an update for the single channel version of the board with more broken out pins to work with, if that helps. I'm also eyeing the ESP32 as a controller, because not only is it faster by a factor of 16 for only $5 more, it's dual core so one could track position while the other does the PID math.

Quote
o_lampe

Is it PWM control you are using to regulate the brushed motors?

BTW: Have you seen the video of my balancing bot with BLDC motors? It goes back and forth and stands still, just like we need for an extruder. But these gimbal motors are pretty weak.

Yep pretty sure every diy motor driver (accept stepper drivers) ive seen for printers uses pwm!

Cool robot.

The balancing Bot works with servo-signal levels not PWM. It is based on a Martinez camera gimbal controller ( not really mass produced, but readily available ) It's firmware is open source. Max coil current is 2A, which is plenty for an extruder.

You guys would probably have the best answer for this.

I was reading about some filament measuring sensor the duet guys are working on and I realized if I'm doing a dc servo..then it basically has built in filament measuring if done right. That got me thinking.... We could stick with Bowden extruders and just move the encoder down to the end of the tube just above the hotend. That way you get the responsiveness of a direct drive with the light weight of a Bowden.

Would that not work? Is there something I am forgetting?

The idea has been brought up, but AFAIK nobody has actually tried it. The easier kinds of closed loop control get brought up far more frequently and yet servos in 3d printers are still vanishingly rare.

FWIW I suspect that the performance of a double loop bowden controller would be rather poor. This is pretty much an absolute worst case control problem - highly nonlinear, noisy, and the plant is influenced by many external factors that cannot be measured or controlled (filament type, temperature, humidity, bowden length, shape of the bowden path)...

Hobbyists generally view encoders as magical machine-correction devices, but in practice you need a very rigid and well built system for stable results. Garage in, garbage out.

Quote
warbunniex
You guys would probably have the best answer for this.

I was reading about some filament measuring sensor the duet guys are working on and I realized if I'm doing a dc servo..then it basically has built in filament measuring if done right. That got me thinking.... We could stick with Bowden extruders and just move the encoder down to the end of the tube just above the hotend. That way you get the responsiveness of a direct drive with the light weight of a Bowden.

Would that not work? Is there something I am forgetting?

Yes I think that could be made to work. The firmware would probably need a model of the behaviour of the Bowden system so that it can use feedforward and not just feedback - in effect, variable pressure advance controlled by feedback.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

O that seems like a much better way of doing pressure advance. Well outside of my abilities but i really like the idea.

Quote
dc42
Yes I think that could be made to work. The firmware would probably need a model of the behaviour of the Bowden system so that it can use feedforward and not just feedback - in effect, variable pressure advance controlled by feedback.

How about an automated PID tuning algorhythm? That way any user can adapt such a sensor to his system.

...if only we could add a real pressure sensor into the melting chamber of the nozzle. That would be the most direct way of controlling extrusion.

Quote
o_lampe
How about an automated PID tuning algorhythm?

I would love to have that. I don't exactly know how to start cause motor position is a bit different from temperature. But if there was a built in auto-pid tune built into the drive that would be awesome. like every time you started a print with a filament, the printer heated up, auto pid tuned the extruder, primed, and then printed. It would be a great way to account for differences in material.

Quote
warbunniex
You mentioned you were having trouble with the firmware side of things. Have you seen this yet?

[github.com]

This is wrong, only the position loop. Here it is made almost as it is necessary. Almost like in the textbook on control theory. But there are also problems with accurate speed measurement for slow movements. I used the fork of this project for my printer.
Still there is a fork on stm32 for two motors, but it has the same problem with speed.

Pamalofeev,

Sorry I'm having a little trouble understanding your post. What do you mean by: "Here it is made almost as it is necessary. "

O also came across this: [techref.massmind.org]

yay more open source closed loop. this one looks pretty intense/ afforable. i really like their magnetic encoders.

Sorry for my bad english..
I wanted to say that this is more correct, but not 100%. There is a position loop, a speed loop and a torque loop. Usually, a torque loop is not used, but a current loop with a sensor. These three loops are necessary for quality work.

Quote
pamalofeev
Sorry for my bad english..
I wanted to say that this is more correct, but not 100%. There is a position loop, a speed loop and a torque loop. Usually, a torque loop is not used, but a current loop with a sensor. These three loops are necessary for quality work.

Thank you for the explanation. I'm not really much of a coder yet and there's plenty about motor control that I don't yet know but maybe I'll get some time soon to look into that.