Hi all.
I am in the planning stages of my (hopefully, one day) PCB-Milling CNC, and I am thinking about how I want to accomplish motor control. As I see it, I have two options.
Place all of the processing burden on my Arduino (or Atmega without bootloader -- haven't decided yet), and just connect 3 dual-hbridges to control each of the three stepper motor axes.
Have each stepper connect to a motor driver that consists of a a dual h-bridge and an attiny or MSP430 (also haven't decided yet) which handles the motor driving and PWM (for microstepping) and just accepts SPI commands from the arduino master.
I'd go for the second method. I like putting intelligence as close to the driver as possible, and distributing the intelligence rather than putting it all in one place. Especially if you're going to do microstepping on 3 axes...that will be very demanding.
It does add complexity with respect to synchronization, making sure that all 3 axes are moving at the same time in the right way. But I think that's a simpler problem to solve than trying to do a circular interpolation while microstepping multiple axes on one processor.
--
The Gadget Shield: accelerometer, RGB LED, IR transmit/receive, speaker, microphone, light sensor, potentiometer, pushbuttons
Are you sure you need microstepping? Leadscrews I've used (0.1 inch pitch) gave .0005 inch per step with a 200 step/rev motor. And 1/2 stepping to 400 is a lot easier than microstepping.
I'd want to analyze the SPI traffic and latencies for any reasonable cutting velocity before deciding to distribute all this..
I once wrote code that ran in an old 16MHz PC motherboard to do this, but it drove a triple timer chip that generated the final pulses for each 3-axis vector move, so I'm not sure what the processing requirements are.
I would first do quite a bit of research on the DIY CNC guys, who have gone a long way with this. TurboCNC etc.
Ok thanks for the advice. I will probably go down the individual controllers road. My idea was just to write the firmware for each controller so that it can accept coordinates from the arduino. That way, i don't have to worry about latencies or messy separate start/stop signals. What do you think?
I agree with Terry, check out the DIY section of the CNCzone forums. Although a lot of people are using Arduino and other microcontrollers to run CNC machines it really doesn't make much sense to me as there is well developed software available (EMC2 and Mach3 are the most notable) that take care of all the interpolation, trajectory planning etc. and provide for auxillary machine functions as well. My choice was EMC2 as it is free, opensource, runs on a 10 yr. old computer I got for free and is capable of anything I could ever need it to do. The bottom line is: if you enjoy the challenge of accomplishing complex tasks with minimal hardware go for the Arduino. If you want to actually make stuff in an efficient manner and not have to "reinvent the wheel" go for a PC controlled system. Arduinos definitely do have a place in the CNC world (there's a project I'm following now for an Arduino based pendant control that sounds interesting). Having said all that, you should check out Grumpy_Mike's milling machine setup if you want to follow the Arduino path: http://www.thebox.myzen.co.uk/Hardware/CNC_Conversion.html.
Yes I had considered using a parallel port motor controller wired directly to the steppers from my old 1998 micron pc...but that seemed so boring. Plus, the arduino solution seems more flexible in the long run. I mean, g code is pretty easy to follow, so my plan was to have a program read a gcode file over serial to the arduino, which then sends the coordinate commands over SPI to each of the stepper controllers.
which then sends the coordinate commands over SPI to each of the stepper controllers.
The problem with having separate controllers is how you synchronise them to make the appropriate diagonal lines or circles or spirals. With all the control in the arduino this is easy as you just have to pulse the appropriate motor.
to have a program read a gcode file over serial to the arduino,
Thanks so much for the links, my goal really is to build this from scratch. For overcoming the synchronization issues, I was thinking I could clock in the next coordinates over spi to each controller and then set something like a trigger pin high to execute the coordinate commands simultaneously... However this method seems like it is becoming needlessly complicated and I may just go for arduino direct to l293d. Besides, thats really the only task that the arduino will be doing,, especially if I don't use micro stepping.
The synchronization issue may be difficult, but interesting. The challenge is to be able to make smooth moves like curves and almost-flat ramps where each step should happen in the exact right interpolation. The easier way is to run that all in the same processor or multiaxis timing chip run from the same clock. But having multiple modular axes and being able to build up multiaxis machines is a good goal.
You don't seem to be looking for Easy but more for Learning, and that's good
I see that about the sync issue. Guess I'll have to work on that. You hit the nail on the head though. If I wanted good circuit boards it would be cheaper to order them, and if I wanted quality milling, ponoko would be 10x better. My goal is a functional mill that i can build from the ground up and understand, while learning something (hopefully a lot).
What about using the spi clock or another clock to time movements that were already clocked in to each controller?
What about using the spi clock or another clock to time movements that were already clocked in to each controller?
It wouldn't have to be SPI any common signal should do. However, you then have all the controllers waiting for the clock pulse and then deciding if to step their motor or not. I don't see any advantage in doing this over just clocking the motors from the one processor. You are making things more difficult than they need to be and that is not the way to learn anything.
I'm not trying to overcomplicate, just to allow for flexibility. My reasoning for doing this in the first place was taking the load off of the main arduino, and the first few replies seemed to support the distributed method. Do you disagree?
Yes, by trying to simplify things by breaking them down you have made things more complicated by breaking a natural link between the controllers and the motors.
It is much much harder to do what you are attempting than to control it all from one processor.
Just think about producing a diagonal line. Using one processor:-
Work out the number of steps from start to finish on the X axis.
Work out the number of steps from start to finish on the Y axis.
Which is the biggest
Divide smallest by largest to get the smallest increment ( floating point number < 1)
Step the largest and increment a counter for the smallest.
If this counter >1 then step the smallest axis and subtract 1 from the counter.
Repeat until you reach the end.
With two processors
Send the finish value for the X axis
Send the finish value for the Y axis
How does each controller know if it has to move the motor the larger number of steps?
start again
Send the finish value for the X & Y axis
Send the finish value for the X & Y axis
Each controller works out if it has the more steps to use by following steps 3 & 4 in the single processor.
The master then sends a pulse to the controllers
Each controller then decides if it has to step its motor and increment it's phantom counter (for the other motor)
The master keeps on sending pulses until the motors reach the destination - oh that means it has had to calculate the number of steps as well.
So how is this a simplification? (answer it is not)
Does it free up any time in the main processor? (answer no)
What use are the individual motor controllers? (answer no use at all)
Ok, thank you. The purpose of this thread was to assess which method was better, and you have made me see that despite many of the other answers to the contrary, it is probably better to keep it all in one controller.
