Oh ok … I thought that the module was the mini and the Rhino was some dev board for a DIP40.
@ kurtnelle: Sorry to bring this tread alive again.
But wauw, i’m not the only one building a CNC machine.
Yours look very cool. I just found out the tread earlier today. And i have looked all your pics and videos.
My own CNC will be much much smaller The frame is 30x30 cm and the work space is now, i think not more then 15 to 20 cm.
I was wondering would you mind sharing your code with me?
Not sure of you ever build the G-code parser as reading your other tread. But that is what i’m searching for, and the linear and arc based movement control.
Anyway i hope you enjoy building it as much as i do. 
@ NielsNL2 (are you from the netherlands?) No problem with the tread, we often do that around here. I’m actually still writing that G-Code parser for a newer machine (see pic), and the problem that I’ve been having is for arc based movement control. I’ve been working on nothing but that for a solid week now and it has been a daunting task.
Linear is straight forward, however arcs are not. The technique that the industry seems to use it to create a motion profile based on trapezoidal profiles which create the arc as a series of short lines that flow one into the other without having the end effector pause between lines.
http://support.motioneng.com/Software-MPI_04_02/Topics/Geometric%20Path%20Motion.htm
[url]http://www.isa.org/Content/ContentGroups/Motion_Control2/Features1/200222/May_June/200206Axes.pdf[/url]
The two links above describe the problem (so that you get an idea of the difficulty).
I am using the dSPIN stepper drivers are you may have read which offloads the stepper motion to the integrated co processor.
Oww that new own does look very nice. Will it be also be able to be used as a 3D printer?
I’m not sure why the arc function does not be that easy for you? When i look at the code used by GBRL then it looks very simple to do.
void mc_arc(double theta, double angular_travel, double radius, double linear_travel, int axis_1, int axis_2,
int axis_linear, double feed_rate, int invert_feed_rate, double *position)
{
int acceleration_manager_was_enabled = plan_is_acceleration_manager_enabled();
plan_set_acceleration_manager_enabled(false); // disable acceleration management for the duration of the arc
double millimeters_of_travel = hypot(angular_travel*radius, labs(linear_travel));
if (millimeters_of_travel == 0.0) { return; }
uint16_t segments = round(millimeters_of_travel/settings.mm_per_arc_segment);
// Multiply inverse feed_rate to compensate for the fact that this movement is approximated
// by a number of discrete segments. The inverse feed_rate should be correct for the sum of
// all segments.
if (invert_feed_rate) { feed_rate *= segments; }
// The angular motion for each segment
double theta_per_segment = angular_travel/segments;
// The linear motion for each segment
double linear_per_segment = linear_travel/segments;
// Compute the center of this circle
double center_x = position[axis_1]-sin(theta)*radius;
double center_y = position[axis_2]-cos(theta)*radius;
// a vector to track the end point of each segment
double target[3];
int i;
// Initialize the linear axis
target[axis_linear] = position[axis_linear];
for (i=0; i<segments; i++) {
target[axis_linear] += linear_per_segment;
theta += theta_per_segment;
target[axis_1] = center_x+sin(theta)*radius;
target[axis_2] = center_y+cos(theta)*radius;
plan_buffer_line(target[X_AXIS], target[Y_AXIS], target[Z_AXIS], feed_rate, invert_feed_rate);
}
plan_set_acceleration_manager_enabled(acceleration_manager_was_enabled);
}
Yes, I keep seeing that approximation technique all over the place, however I’m convinced that there is a way to do it by controlling the acceleration of the axes.