Since the Icepick-delta is a true non linear deltabot, it requires some math to move it. It turns out this has done this before (yay!). A big thank you to mzavatsky for writing the inverse kinematics code and bigdaveakers for making it so much easier to incorporate into marlin.

Replacing the delta functions in marlin_main.cpp and adding defines to configuration.h and we have results!

#ifdef DELTA
float f = BASE_SIDE;
float e = END_EFFECTOR_SIDE;
float rf = DELTA_ARM_LENGTH;
float re = DELTA_DIAGONAL_ROD;
const float sin120 = DELTA_SIN120;
const float cos120 = DELTA_COS120;
float x0;
float y0;
float z0;
// the function is called with like so at another point for the M665 gcode command: recalc_delta_settings(delta_radius, delta_diagonal_rod);
// for initial testing, this will be ignored
int delta_calcAngleYZ(float x0, float y0, float z0, float& theta)
{
float y1 = -0.5 * 0.57735 * f; // f/2 * tan 30
y0 -= 0.5 * 0.57735 * e; // shift center to edge
// z = a + b*y <-- what is this for?
float a = (x0*x0 + y0*y0 + z0*z0 +rf*rf - re*re - y1*y1)/(2*z0);
float b = (y1-y0)/z0;
// discriminant
float d = -(a+b*y1)*(a+b*y1)+rf*(b*b*rf+rf);
if (d < 0) return -1; // non-existing point
float yj = (y1 - a*b - sqrt(d))/(b*b + 1); // choosing outer point
float zj = a + b*yj;
theta = atan(-zj/(y1 - yj))*(180/DELTA_PI) + ((yj>y1)?180.0:0.0);
return 0;
}
void calculate_delta(float cartesian[3])
{
// inverse kinematics: (x0, y0, z0) -> (theta1, theta2, theta3)
// returned status: 0=OK, -1=non-existing position
float theta1 = 0.0;
float theta2 = 0.0;
float theta3 = 0.0;
x0 = cartesian[X_AXIS];
y0 = cartesian[Y_AXIS];
z0 = cartesian[Z_AXIS] - DELTA_HOME_POS;
int status = delta_calcAngleYZ(x0, y0, z0, theta1);
if (status == 0) status = delta_calcAngleYZ(x0*cos120 + y0*sin120, y0*cos120-x0*sin120, z0, theta2); // rotate coords to +120 deg
if (status == 0) status = delta_calcAngleYZ(x0*cos120 - y0*sin120, y0*cos120+x0*sin120, z0, theta3); // rotate coords to -120 deg
delta[X_AXIS] = -theta1;
delta[Y_AXIS] = -theta2;
delta[Z_AXIS] = -theta3;
}

That's a lot of math, just for one segment of a move. The Arduino calculates X number of segments per second, as defined in configuration.h. That's all fine and well, but with this much math, the Arduino can only handle 40 segments per second :(

At 40mm/sec, it would result in 1mm long segments. Much too large! The regular linear delta firmware such as the Rostock, can manage 200 segments per second on the Arduino mega.

What to do?

At this stage, I'm thinking optimize. I found a forum post by Jamesdanielv on replacing the square root function with the one he has posted. He claims it is 3 times faster, and is accurate within 3.5%. As an experiment, I replaced all square root function in the firmware with the faster one, this resulted in a new maximum segments per second: 50. A 20% increase. Not bad. Still far too slow.

I'm not comfortable replacing all square root functions. I'm unsure that the function will work in all cases after some members commented that it will not work in all cases (buffer overflows or something?). I may do some more investigation and use it later.

Next up we have the arctan function in the code, perhaps this can be sped up? Doing some googling, it appears a lookup table may be the answer..

Worst case scenario I could always upgrade to something with an ARM proccessor, but I'm reluctant, after all, the project goal is to develop a reprap with a rock bottom bill of materials.

To be continued..

First of all: I very much admire your ambition and work ethic in making this machine, and making it work. Thou art indeed the man.

As for for printing accuracy: You've had a couple years to think about it now, and I want to ask you a few questions please.

Today, how much of the IcePick's printing inaccuracy do you mentally chalk-up to the harder inverse-kinematics sticking you with just ~40 segments per second?

As for tooth-belts, plenty of linear-slide delta-type machines do just fine with tooth-belts, so do you still (partially) "blame" the arms (instead of linear-slides) for its inaccuracy problems?

In general, I'm puzzled as to why there's be so little work being done on delta-arm type machines like this. I'm not calling the whole world stupid, but I AM genuinely confused as to what their inherent deficiencies -- if any -- might actually be. So your comments will be very much appreciated. And thank you.