CNC machines work in Cartesian coordinate systems. It is the standard XYZ coordinate system that gcode uses. Most CNC machines have motors that directly move in the Cartesian system. Kinematics is used when you have complex machines where multiple motors need to be coordinated.
You add a kinematics: group at the top level of your config file. Each type may have sub item. Below are some examples.
This is the default system.
kinematics:
Cartesian:
kinematics:
corexy:
Getting the directions right can be tricky. If motors are swapped or the motor directions are not right, you will get incorrect motion. This is one method to sort it out.
Manually turn one motor at a time with the other held firmly until the the end effector moves in positive X and Y (45 deg). Remember which motor you turned and which direction you turn it.
No send small jogs like this $J=G91 G21 X5 Y5 F200
You want the motors to do the same thing you did manually.
If the wrong motor moves, swap the motors
If the correct motor moves, but the wrong way then change the direction attribute (:high vs. :low) of that motor.
Restart and test again.
If that jog works, then try jogging other directions. If that is not right, the only thing that could be wrong is the other motor's direction.
kinematics:
midtbot:
The wallplotter code was contributed by a user. The primary developers are not actively maintaining the code or providing support. If you have questions create a post on Github. You should also search for other issues for
Wallplotter
and directly ask those users.
This kinematics does not use homing. You must manually move the pen to the 0,0 position as defined by your config settings and then reset the firmware. In the example below, you would move the pen to the center on X and 100mm below the anchors
.
It is probably easiest to make sure your motors are correctly defined by doing the initial testing with Cartesian kinematics. This will allow you to move each motor by itself to make sure it works properly. Make sure an X move moves the left motor and a Y move moves the right motor. Make sure both motors move in the proper directions. A move in the positive direction feeds out more cord.
kinematics:
WallPlotter:
left_axis: 0
left_anchor_x: -100.000
left_anchor_y: 100.000
right_axis: 1
right_anchor_x: 100.000
right_anchor_y: 100.000
segment_length: 5.000
This is an experimental feature, currently only available on Devt branch.
This kinematics is used to control tangential knife or oscillating knife. The knife is tangent to the direction of the cut, knife orientation is motorized on C axis. C axis motor position is computed for each XY move to be tangent to path. It means you can use standard XY or XYZ G-CODE.
Many die-cutter do not have a motorized Z axis but use a pneumatic stage to move the cutting head up/down. Electrovanne of pneumatic stage can be controlled using solenoid motor. In case of pneumatic Z axis, your G-CODE only need XY information. For motorized Z axis, G-CODE should provide XYZ data.
This kinematics is not compatible with drag knife. Drag knife orientation is not motorized but free to rotate along Z axis, the offset betwwen knife tip and axis create a moment so the knife is following the cutting.
Drag knife path should be generated by the g-code generator.
A tangential knife is always tangent to the direction of motion. When orientation change, the knife is rotated outside the material (lift) or inside the material before or during the move, depending on the following parameters :
These are defaults values that I recommend as initial settings.
kinematics:
TangentialKnife:
tan_knife_safe_angle_deg: 3
tan_knife_blend_angle_deg: 1
tan_knife_blend_distance_mm: 50
tan_knife_lift_distance_mm : 5
tan_knife_z_axis_is_pneumatic: true
tan_knife_cutting_height_mm: -1
The types listed above are compiled by default and you can simply add them to your config file. In the future some less popular types may be added and will not be compiled by default. Those will require a #define added to the kinematics.h file.
You can create a new type by adding a new class that is derived from the KinematicSystem class. If your machine is still based on the Cartesian system, like CoreXY, you can derive from Cartesian.
Look at all the virtual functions in Kinematic.h. You will probably want to override most of them in your class. You can search the main code to see how these are called. You can also look at other examples like CoreXY to see what is done.
There is a functional parallel delta kinematics on Grbl_ESP32, that might give you a head start if you want that type of kinematics.
The answer is probably not. It is a lot of work and requires a machine to test on. We are happy to include your code if you write a new one.