Mechaduino Closed-loop Stepper

I ran across a new closed-loop stepper controller that might be a great solution for 3D printing: http://hackaday.com/2016/06/01/mechaduino-closed-loop-stepper-servos-for-everyone/ It looks like they are doing something very similar to my closed-loop stepper project (described in this post) where you turn a stepper motor into a brushless servo motor, but this one is potentially a lot cheaper. In particular, it looks like they've found a good low-cost encoder solution. They may be doing a Kickstarter, so they may become widely available.

It may correct for disturbances to the position of the motor, but without firmware in the printer that senses the disturbance and corrects the extrusion as well, it's sort of pointless, isn't it? I think you'd need an output from each of the servo boards to the controller to indicate that it is not in its correct position so the extrusion could be interrupted until the motor has made the correction. Will you also stop the other motors while the error is corrected?

While it's an interesting idea, it doesn't eliminate the need to design a mechanism that doesn't bind. If the printer mechanism doesn't bind there's no reason for it to lose steps. If it doesn't lose steps, there's no need for closed loop control. Grabbing the extruder carriage isn't part of the normal operation of the machine. You could fix problems caused by people grabbing the extruder carriage by putting in servo control of the motors but how do you correct for someone pushing the printer off the table (which is as valid an operating mode as someone grabbing the extruder carriage)?

It seems to me the only reason for using closed loop control is to allow cheapo DC motors to be used instead of steppers. This doesn't do that. What's the point?

Edited 1 time(s). Last edit at 06/03/2016 10:26AM by the_digital_dentist.

---

Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]

DD: I largely agree with you - a well designed XYZ mechanism won't slip steps. Given the vagaries of the extrusion process, however, the extruder motor could definitely benefit from closed-loop control, especially if you add some firmware mods to monitor the servo errors. Also, with closed-loop control you can generally use a smaller motor which would be a benefit for direct-drive extruders.

The interesting thing about turning steppers into servo motors (rather than just using standard DC motors) is that steppers run at higher torques and lower speeds that are generally more convenient for robotic applications. DC motors will almost always require several stages of gearing which introduces more expense and backlash.

What happens when the extruder misses a few steps midtrack and tries to keep up with the stepcount later? ( say, there is a blob on the lower layer, blocking the nozzle)
It will create more blobs, because it adds filament where it shouldn't.
Sometimes on very tricky parts, I'd better like the extruder to skip a few steps, rather than forcing filament on the wrong place.

PS: I'd like to see the stepper current regulated by the closed loop, that would be a better solution IMHO

Edited 1 time(s). Last edit at 06/03/2016 11:29AM by o_lampe.

Quote
o_lampe
What happens when the extruder misses a few steps midtrack and tries to keep up with the stepcount later? ( say, there is a blob on the lower layer, blocking the nozzle)
It will create more blobs, because it adds filament where it shouldn't.
Sometimes on very tricky parts, I'd better like the extruder to skip a few steps, rather than forcing filament on the wrong place.

PS: I'd like to see the stepper current regulated by the closed loop, that would be a better solution IMHO

I don't know how the Mechaduino handles various error situations. In my implementation, I included a mode where an excessive servo error would disable the servo and then restart it from teh current position - more or less equivalent to skipping steps. The Mechaduino is Arduino compatible and open source, so I'm sure it'll be possible to create whatever error handling behavior you want.

Quote
o_lampe
What happens when the extruder misses a few steps midtrack and tries to keep up with the stepcount later? ( say, there is a blob on the lower layer, blocking the nozzle)
It will create more blobs, because it adds filament where it shouldn't.
Sometimes on very tricky parts, I'd better like the extruder to skip a few steps, rather than forcing filament on the wrong place.

PS: I'd like to see the stepper current regulated by the closed loop, that would be a better solution IMHO

For a 3d printer you need to couple X, Y (and Z for deltas) with extruder movements to ensure proper release of the melted filament in the right spot while keeping the nozzle pressure as close to constant as possible (except for retractions). If you use Mechaduino just for the extruder you might get some feedback regarding jams, although that might be too late and you won't be able to catch ground filament that doesn't move anymore.

Also, if you could get Mechaduino linked with multiple encoders and steppers, you basically get a reliable motion control for our printers minus the hotend/hotbed/fans. Not sure the pricing would be an advantage -- if you add another say Pi Zero for Gcode and interfacing and some shield board with MOSFETs for the rest you're pretty much getting over RAMPS and Smoothieboard. Thus, I think the market for such solution is CNCs, robots and others less price sensitive. People are looking into < $200 printers and based on the inkjets history that means DC motors not steppers.

I'm the designer of the Mechaduino, so I thought I'd chime in here:

If you use Mechaduino as a drop in replacement for a stepper motor, extrusion will continue and you may see a blob or small defect. Mechaduino will correct for disturbances, but there isn't feedback to the controller on tracking error in this setup. I see this as being most useful for really large prints where a skipped step 8 hours in means a ruined print and that you have to start all over... but a small blob, potentially inside the print, may not bother you. Personally, I'll take a small defect over a ruined print any day

I also had the Mechaduino in mind for novel printer architectures that use direct drive mechanisms. For example: my delta printer.

On this printer I have to turn the current up pretty high to avoid missing steps, and it still occasionally happens. Unlike on a cartesian printer, a skipped step here means 3 dimensional distortion and a ruined print

The Mechaduino does have closed loop current control. Since it is a servo motor, it only applies torque when necessary meaning lower power consumption, cooler motor and driver, and higher peak torques.

Drop in replacement is pretty straightforward and eliminates the need for stepper drivers on your RAMPS board. You could also get fancy and eliminate limit switches (The Mechaduino has absolute encoders, and you could also use hard-stops on each axis and torque sensing on the Mechaduino to detect the limit). It occurs to me that you could even try to detect jams by using a Mechaduino on the extruder and monitoring torque.

BUT... you are right: There are limitations to this approach. If you really want to push the envelope here, you would feed back information to the controller. I think Mechaduino would be an ideal tool for playing with these ideas. All you would have to do is wire up the additional feedback signals. You can configure the Mechaduino's digital IO/Serial/I2C to send error signals back to the central controller. I could even see all the Mechaduinos being on a single I2C bus and using it for both commands and feedback. Then you wouldn't even need a full RAMPS board, just a simple shield for extruder/bed control.

It's all open source, so you can make the Mechaduino behave however you want in an error situation. You can edit everything from the Arduino environment so you don't need any special software tools or hardware. Code and hardware design files are on github.

I hope that answers your questions. The Mechaduino is still very much under development, so your feedback is greatly appreciated! We're hoping to make them available through a small kickstarter soon for around $50-ish. We're trying to get that cost as low as possible so more people can get there hands on them!

jcchurch: Great job on the Mechanduino! Just a few of questions:

- Can you give more details on the encoder? Does it need an extended shaft on the back of the motor? What is its resolution and absolute accuracy?

- Does the Mechaduino code support phase advance? What sorts of motor speeds are practical?

Edited 1 time(s). Last edit at 06/09/2016 02:15PM by LoboCNC.

Thanks LoboCNC!

We are using an AS5047 14bit (16,384 counts per rev or 0.022 degree) magnetic encoder from AMS. Be warned: all magnetic encoders that work on this principle suffer from large (~ a degree or so) non-linearities, so we had to develop a calibration routine. Details here. We are very pleased with our calibration routine and we believe our accuracy is at least better than +/-0.05 degrees (we need to do some more testing).

Phase advance is supported, although we haven't played with it too much. Without any phase advance or optimization for high speeds we are hitting speeds around 300 rpm, but this could definitely be improved upon in firmware.

Edited 2 time(s). Last edit at 06/09/2016 02:31PM by jcchurch.

0.05 deg encoder accuracy is pretty remarkable. Do you have any estimates for dynamic and static servo positioning errors?

Also,it's really worth optimizing the phase advance. On closed-loop stepper systems I've built with properly tuned phase advance, I've been able to get over 3000 RPM (running a 4v motor with a 24v supply), although the usable torque peters out at more like 1500 RPM.

Edited 1 time(s). Last edit at 06/09/2016 08:23PM by LoboCNC.

As with any servo motor, dynamic positioning error will depend on the load connected to the Mechaduino and how well the Mechaduino's controller is tuned. Static positioning error is forced to zero (there is an integrator in the control loop which forces zero steady state error).

I'll have to play around with the phase advance. Those are some pretty impressive speeds for a stepper motor!

What do you see as the advantages and disadvantages of this system compared to a closed-loop DC gear-motor setup?

Quote
epicepee
What do you see as the advantages and disadvantages of this system compared to a closed-loop DC gear-motor setup?

The main advantage of closed-loop steppers is for high torque/low speed applications where you can get use them without any additional gearing. Also the fact that they are drop-in replacements for systems designed for conventional NEMA steppers makes them really convenient to use. Closed-loop DC gearmotors, though have a better power/weight ratio are better for applications like direct-drive extruders where weight is a big concern.

We chose to base Mechaduino around stepper motors for a couple of reasons. In addition to the technical specs pointed out by LoboCNC, there was also some consideration of the economics :

Most industrial servos use brush-less dc motors. Stepper motors are essentially high-pole count brush-less dc motors. Since stepper motors are mass produced, they are a great way to get a high quality motor for a very low price. Compare the price of a stepper motor to a similarly sized bldc motor and you'll see what I mean!

Stepper motors are standardized (NEMA frame size) and used everywhere (especially rep raps!). They are more generic than gear motors. If someone says Nema 17 stepper, you have a pretty good idea of what you're dealing with. Many companies make them, so they are priced competitively. Gearmotors are less standardized. Every motor company has their own series of gearmotors, making them more expensive and less interchangeable. Also, the gearbox drives the cost up. Yes you can find cheap gearboxes, but they often have significant backlash. If only there was an affordable harmonic drive gearbox...sigh.

Yeah, backlash was a big reason we avoided gear-motors. We wanted Mechaduino to be usable for precision pointing and positioning applications, and there really isn't any other affordable solution to this out there right now.

Hi All,

I just thought I would let you know that we've launched a Kickstarter for Mechaduino!

-Joe

I have started a digikey shopping basket here [www.digikey.co.uk] but I am unsure of what voltage the caps should be and what wattage and % the resistors are. so I have not added them yet.

The latest BOM is here:
[github.com]

If I remember correctly, C6, C12 and C13 are the only caps that see anything over 5V (I'd use caps rated at least 25V). The only parts where I would really be concerned about tolerance are the sense resistors (R12,R13).

Hope that helps.

Thank You ! thats is a big help. ill add them to the shopping basket


thanks Nikki

The Mechaduino may have a good application
where smooth drive is required.
I was thinking of telescope drive motors
or
smooth pan / tilt for camera.

but then again a true feedback of angle advanced at end would be best

Would it be possible to put encoder on final drive

but just an error report after the fact?

I have updated the basket [www.digikey.co.uk] I think ive added the full BOM but please double check it before ordering


Nikki

I have made a stepper controller like the mechaduino but with some additional features [misfittech.net].

First off there is a error pin. If an motor skips a step then the error pin is asserted until the NZS fixes the problem. This could be used by Marlin to stop the other motors until the error has been fixed. For example if the extruder binds and misses a step then error pin is set and Marlin could stop the X, Y, and Z motors until the error is fixed. This is not implemented in Marlin yet but the NZS has the capability.

Second there is an LCD such that you can calibrate without requiring you to recompile and reprogram firmware. The LCD also allows for feedback and DRO capabilities.

Third the driver's heat sink is soldered to PCB for better heat and higher currents on motors.

Fourth the firmware is complete rewrite with numerous bug fixes.

Details about the development and testing can be found on the blog at misfittech.net, additionally the hardware is in stock and ready for shipment.

Of course the firmware and design is open source.

Thanks
Trampas

---

Stay in control of your stepper motors - [misfittech.net]

I forgot to mention that with the error pin and ability to change the motor current on the fly it is possible to have Marlin tell the NZS to lower the drive current on the motor. Then run the extruder head into the plate until the error pin is asserted. This would basically allow homing of the Z axis using the head, which then in turns makes bed leveling easy.

Here is a test I was doing on a PNP head to see if I could detect when head hit something:
[www.youtube.com]

Trampas

Edited 1 time(s). Last edit at 12/02/2016 08:21AM by trampas.

---

Stay in control of your stepper motors - [misfittech.net]

Sweet looking board Trampas! Love the idea of the little display on board

Here's a link to a photo form Trampas' website to wet the appetite of anyone who wouldn't otherwise follow a link:



Edited 1 time(s). Last edit at 12/03/2016 02:36PM by JamesK.

Thanks, it has taken me months to get everything working. There is still more work to be done but I am happy with the results.

Trampas

---

Stay in control of your stepper motors - [misfittech.net]

Trampas, Great work! Does your version of the code implement phase advance in the motor commutation? This can dramatically increase the top speed of the motor.

What is the maximum current allowed for the stepper?
How hard would it be to move the input buttons and LCD to a remote location?

The LCD is a nice feature, is it required to have one for each driver or can it be daisy chained?

The code does implement phase advancement which in simple terms, allows dynamic step size on the stepper motor. That is the driver code for the A4954 implements 256x microstepping, while I have normally been running the external interface at 16x microstepping. So what happens is when a user requests a step internally the firmware calculates what the desired angle is, then it measures the current angle using an encoder and compares to the desired angle. It will then move the motor the difference to achieve the desired position. What this means is that if the error is large (fast movement) it will take larger steps, if error is small it will take smaller steps.

The LCD is I2C LCD thus it has 4 wires (power, ground, SDA, SCL). I have been using jumper wires to move the LCD where I can see the shaft and LCD at same time.

I have not implemented daisy chaining as that I figure the host (Marlin/Smoothie) should have an LCD to handle multiple axis.

How does homing work with a smart motor setup like this? Presumably you want the motor controller to know when it is at the home position, so do you connect the endstop to the motor controller and let it take care of homing?

Currently the motor controller knows nothing about home position. To gain perspective on this think about the motor sitting on a bench, it has no idea which way is zero degrees, all it knows that from where it is now it can move xxx degrees. Hence the controller right now arbitrarily sets a position as zero degrees and then measures all angles relative to this starting position.

Homing is unique to some machines, not all applications of the controller have a concept of home, for example controlling a rolling press.

Homing therefore is a function of the host (Marlin). How the controller can help with homing is that you can control the force the motor uses by setting the current. So for example I could turn down the current on the controller to just above what it takes to move the rails of my machine. Then I could run the motors to the end stops of the machine, when the motors reach the mechanical end stops it can not move any further and the error will go up. This way you could eliminate the limit switches on your machine. Once you have homed you would then increase the controllers current for normal operations.

A video showing the error detection for a pick and place head is here: [www.youtube.com]

One thing is the firmware for Marlin would need to be changed to communicate with the NZS such that you can change the current dynamically to do this homing. Basically what I was planning is that using the "error pin" as an enable signal, and have it when this enable signal is held low the step and direction pins change functionality into a UART. Then Marlin firmware could bit bang commands and responses from the NZS. This would enable Marlin to set current low and do the homing, then set current back high.

My main goal for the homing is for bed leveling, this way the nozzle would be used to measure the bed height and you would have perfect bed leveling.

Trampas