Basic Information:
Printer Model: Custom
MCU / Printerboard: Bigtreetech Manta M8P
Good day! Does SCARA kinematics exist in Klipper?
AFAIK, no.
Sadly 
Good day! We are trying to make SCARA kinematics for our machine, but unfortunately there are some problems with it.
We have derived a formula that calculates the angles by which the X and Y axes should be rotated. For the sake of scientific interest, we put the obtained formulas into Cartesian kinematics.
For example for the Y axis this formula:
static double
cart_stepper_y_calc_position(struct stepper_kinematics *sk, struct move *m
, double move_time)
{
struct coord c = move_get_coord(m,move_time);
return (180 - (2 * (acos(((sqrt(c.y * c.y + c.x * c.x))/(2 * 1220))) * (180/M_PI))));
}
After a short compilation of the kinematics, the web interface calmly opens, but when trying to send the printer home along any axes (even Z, which was not changed), an error occurs: Internal error on command: "G28" and Klipper turns off.
And a couple of questions arose:
- What causes this error?
- Is it possible to see what value Klipper calculated for the Y axis?
- Can you give additional tips on creating new kinematics, beyond the information that is in the documentation?
With best wishes, Slava.
2 Likes
Cool think 
Just curious, what do you want to print with that cute monster?
Please attach a klppy.log. Without, no one can guess you.
1 Like
Unfortunately, at the moment I do not have access to the board, but as soon as I have the opportunity, I will immediately send it!
This printer is designed to print prefabs or specific objects, for example:
With best wishes, Slava.
2 Likes
Klipper does not support the SCARA kinematics.
See Kinematics - Klipper documentation and Code overview - Klipper documentation for some high level information what it would take to make it work.
Also see [WIP] morgan_scara: Initial support for RepRap Morgan style SCARA printers by noahwilliamsson · Pull Request #2368 · Klipper3d/klipper · GitHub for an attempt that apparently has never been finished.
I’m not aware that any developer is currently working on it.
1 Like
Very impressive and nicely made printer.
1 Like
We tried to install morgan_scara on our machine, an error came out and we immediately went in other ways, we probably still need to sit longer with it 
Although not a common kinematics, it surely be a welcome addition to the Klipper zoo. 
2 Likes
I’ve seen a few people inquire about scara kinematics recently. However, I don’t know of any finished products. The furthest code I’ve seen was the work done by @bondus a couple years ago - 5barscara/FiveBarElbowKlipper at master · bondus/5barscara · GitHub .
It’s hard to say what caused the Internal error on command without seeing the full log.
Cheers,
-Kevin
1 Like
Good day! Here is the log file 
klippy (1).log (115.0 KB)
ValueError: cannot convert float NaN to integer
The following formula is used for the X-axis:
static double
cart_stepper_x_calc_position(struct stepper_kinematics *sk, struct move *m
, double move_time)
{
struct coord c = move_get_coord(m,move_time);
return ((acos(c.y/(sqrt(c.y * c.y + c.x * c.x)))*180/M_PI) + 90) - (( 2 * (acos(sqrt(c.y * c.y + c.x * c.x)/(2 * 1200)) * (180/M_PI)))/2);
}
And according to this formula, with c.x = 0 and c.y=0, we get NaN at the output
We are ready to pay for setting up SCARA kinematics, we are very much interested in this
At 0,0,0 the math break down and you get a division by error, NaN as a result.
I made a 5-bar scara kinematics a few years ago, it worked. The 5-bar scara is similar in many way to the normal scara, only the math for the arms is totally different.
It’s not easy to create a new kinematics. Specially a non-linear kinematic, you have to do some trickery to make klipper behave when you home the printer
The easiest solution is probably to get a Duet3D board and use the RepRapDFirmware. It has, as far as i know, full support for Scara. Configuring RepRapFirmware for a Serial SCARA printer | Duet3D Documentation
Initially, we were on the FLY-407ZG RepRap 
, but then we switched to Bigtreetech Manta M8P because it has more stable WiFi Web Control, a webcam is easily connected and it is more convenient to set up control of additional equipment. We are completely satisfied with the Klipper firmware and the control board, it remains only to configure the Scara Kinematic
I believe Dobot had an operational Scara like printer: https://www.youtube.com/watch?v=SqJyx5qIsEk
Not sure what firmware they used.
1 Like
Good day! A short report on the work done Polar kinematics was used as a basis instead of the usual Cartesian, we can say that we are trying to deceive klipper by presenting ourselves as a printer with polar kinematics.
And that’s what happened to print:
Everything would be fine, but when printed, the circle looks more like an oval, the square looks more like a parallelogram. It is not good We tried to use the above-mentioned implementations of SCARA kinematics, but without success. The only thing that more or less worked for us was the option with polar kinematics, despite its features (homing, etc.)
Kinematics settings
At the moment, we have changed the calculation of the bed angle in the function polar_stepper_angle_calc_position:
static double
polar_stepper_angle_calc_position(struct stepper_kinematics *sk, struct move *m
, double move_time)
{
struct coord c = move_get_coord(m, move_time);
// XXX - handle x==y==0
double angle = (atan2(c.y, c.x))-(cos(sqrt(c.x*c.x + c.y*c.y)/2440));
if (angle - sk->commanded_pos > M_PI)
angle -= 2. * M_PI;
else if (angle - sk->commanded_pos < -M_PI)
angle += 2. * M_PI;
return angle;
}
The hand calculation remains unchanged:
static double
polar_stepper_radius_calc_position(struct stepper_kinematics *sk, struct move *m
, double move_time)
{
struct coord c = move_get_coord(m, move_time);
return sqrt(c.x*c.x + c.y*c.y);
}
The kinematics class itself also remains unchanged. In our opinion, changing the calculation formula in the polar_stepper_radius_calc_position function will help eliminate the problem with inaccurate printing. Returning (cos(sqrt(c.x*c.x + c.y*c.y)/2440)) instead sqrt(c.x*c.x + c.y*c.y), at the same time, adding the property units_in_radians=True in the kinematics class for the hand. However, with such settings, the “arm” (Y axis) begins to go home in the opposite direction, and not together with the “bed” (X axis) as it was before. And the most incomprehensible thing is that when the “bed” (X) moves at the command G1 X1 F100, we make a sharp jerk and go into error due to the driver.
This is where I end my story, I will be glad to hear your ideas, suggestions, errors and words of support 
Hello everyone again! More specific information about our printer:
-
Our printer is left-handed, arm No. 1 (X axis) measures 1222 mm, arm No. 2 (Y axis) measures 1206 mm
-
Inductive sensors are used as endstop switches; their location can be seen in the figure, as well as the home position of the printer.
If you look at the second picture, the X axis moves clockwise, the Y axis moves counterclockwise
At the moment there are only 3 such sensors and they are set to the minimum position (home), so far there are no sensors for the maximum position -
View from the outside
-
Kinematics files, as well as klipper log, which are now used for printing
polar.txt (5.1 KB)
klippy.log (42.0 KB)
kin_polar.txt (1.8 KB)
1 Like
