Very awesome work being done with an arduino pro mini (which can be had for less than $2/ea) controlling each axis with step/direction input and a DC motor.
This looks like it may be a worthwhile solution for servo-driven machines.
Originally shared by Miguel Sánchez
Exploring the way for handling two DC motors per Arduino.
http://fightpc.blogspot.com/2015/01/do-more-with-less.html
Am I missing something or is he using an open loop to control a closed loop?
I’m already doing something similar with small Arduino and a “DFRobot - Dual 2A DC Motor Controller (L298N) DR-DRI0002” I got from RoboSavvy, though my “encoder” to control things is very different. Not for 3D printing, but inspired by it, and some parts will be 3D printed. <3 Arduino!
BTW, the Digispark ATTINY85 Micro USB Development Board is great if you want something even smaller: Arduino IDE 1.0+ support, power via USB or external with on-board 500ma 5V regulator, built-in USB,
6 multifunction I/O Pins (2 used by USB if program communicates over it), ~ 6K flash after bootloader, I2C & SPI, hardware PWM on 3 pins, ADC on 4 pins, power LED and Test/Status LED (on Pin0). Weighs in at 4g, only 2.6x1.8cm.
So inexpensive why make a custom board? (“Because I can” and “Because I learn from it” being very valid replies)
@Matthew_Satterlee Using step and direction signals as inputs, a closed-loop position control si done with the help of an encoder that measures the movement of motor shaft.
@Miguel_Sanchez , is there any feedback from the servo loop to Marlin?
@Matthew_Satterlee why would there need to be? In fact, it would probably be more detrimental to printing than the way this is set up. Marlin just simply doesn’t have the free cycles right now. Having a bunch of extra arduinos at the motors (for $2/ea) isn’t a bad deal at all.
A number of reasons… Tuning for speed and accuracy through data logging the commanded position, duty cycle, position/acceleration error. Error reporting to stop the machine in case of a failure. Better coordination of movements and extrusion (assuming a servo extruder is used).
all of that stuff can be done on each arduino, there’s literally no need to tie them back into marlin. All you’re going to end up doing is wasting even more cycles on this stuff that we already don’t have. We don’t have the extra processing cycles to be adding anything else to Marlin. At most, you need step/direction/enable. That’s what our current drivers use, and it’s perfectly fine for this project as well.
Feedback does not have to be data intensive. A simple error bit could alert Marlin of something like prolonged/repeated position errors (clogged hotend).
@Matthew_Satterlee Feedback to Marlin is not provided at the moment. However, someone suggested that extrusion be interrupted whenever there was a significant position error.
In this video https://www.youtube.com/watch?v=L-_5KsAOVko you can see X & Y axis being driver by the above logic and when the carriage is pulled away from its course extrusion is still happening.
However, something like an error pin could be, easily, provided back to Marlin. But at the moment I am working on making the control smarter by pushing the part of motion planning from Marlin into a multi-motor controller.
@Miguel_Sanchez just watched the video, the fact that the Arduino controlling the motors has an encoder disc, can get the feedback that the head has been moved and correct for it is a major step forward. We don’t get that with the current steppers where errors get compounded. Bravo!
If you do add an error pin maybe instead of monitoring it all the time the Marlin code does a “Tuning test” first. Just as it can currently z-probe before printing you could have it accelerate the print head around corners, circles etc looking to see how fast it can push things before errors are reported. Then print at n% of that maximum knowing the hardware will cope.
Do you have enough pins to implement SPI so that Marlin could read an error profile not just get a binary Ok/Error?
@Mark_MARKSE_Emery Sure, unused pins there are plenty but processing power available not much (unless you dial down the PID sample rate).
You wouldn’t need much. Just as we have G29 Detailed Z-Probe you could have a new G code that goes through a number of set moves and speeds, each time stopping to talk over SPI to get a report. That report could be number of steps done and error counts. Once you’ve gone through a tuning process Marlin could log the top error free speed to move at into EEPROM. Then you get on with printing letting the motor Arduinos do their own thing. The motor Aduino would just need to keep incrementing a counter each time it steps or detects an error.
@Mark_MARKSE_Emery yeah - I could certainly see this being used for endstops as well. Being able to detect machine extents. Lots of stuff can be done with it.
Does this mean that, since we’ll be able to log the current position of the extruder, we could potentially send that data to the cloud/database in realtime? Interested cause that would help with implementing a “resume” feature when errors occur. Keep up the amazing work!
@Greg_Carron_pixeladd Each motor’s controllers know the actual position of the motor and it could report it back to the main controller, which in turn may report it to the cloud. Or you can just use an inexpensive wifi SoC to report it back to the net like ESP8266 (one per motor controller would be needed if you go this route).
Thanks @Miguel_Sanchez for your work. I wanted to put effort in this but i just started college full time and don’t have the necessary knowledge and limited time to tinker let alone figure how to make it work. Awesome work. This will change the way we print!
Any reason why you couldn’t make them on a board pin compatible with a RAMPS Stepper Driver? http://reprap.org/wiki/StepStick you’d need a jumper from the board back to other RAMPS pins for SPI etc, but it would make pulling your design into a build far easier.