terjeio
commented
1 year ago The main difference is that the grblHAL planner requests segments from the kinematics implementation, ESP32_GRBL pushes them. The grblHAL wall_plotter kinematics implementation is similar to the polar implementation in that motion is split up into many small segments so IMO can serve as a starting point. The wp_segment_line() function in grblHAL is equivalent to cartesian_to_motors() in ESP32_Grbl.
When a move is executed wp_segment_line() is called with the init argument set true. This signals that the function has to calculate the the number of segments (iterations) and other data needed for the move. This information is stored in local static variables to be used later when calculating the segment positions. After this call the planner will call the same function again with init set false, the function then returns the next position. The function will then be called repeatedly until all segments has been calulated and delivered.
Jog cancel handling is different: the kinematics routine subscribes to the jog cancel event and when "fired" sets a flag that causes wp_segment_line() to return NULL. This tells the planner that there are no more segments available.
I have not looked into how homing differs. I see that ESP32_Grbl likely rehomes the machine at end of each job (when M30 is executed). This can be done in grblHAL as well by subscribing to the grbl.on_program_completed event.
Melkiyby
Please help with adding this kinematics to GRBLHal. There are a lot of differences in the GRBL structure that I have not figured out. https://github.com/bdring/Grbl_Esp32/blob/main/Grbl_Esp32/Custom/polar_coaster.cpp