I imagine these commands will be parsed into a single or various circular buffers.
When doing the motion planning we then look at the move/command being performed now, the next command in line, and to give us some time-to-react we look at the buffer[10] or the 10th command in line, mainly to check whether the trapezoid state (accel/cruise/de-accel) will change in the foreseeable future. If the motor is sagging behind the commands (this all happens really fast) the controller will apply more current/torque, until a certain limit. Position in time, not to forget will tie the whole apparatus together
This is the link to our beloved Gcode. A.k.a. adaptive clearing.
You can develop an interpreter of Klipper commands making possible to run Klipper on the same microcontroller that you are using for your SimpleFOC instance, effectively creating a “Klipper Node.”
However, in my opinion, this is not in line with the purpose of SimpleFOC, as it operates at a higher layer. If you look at examples such as oDrive, VESC, or Moteus, none of them go beyond basic motion planning for a single axis.
@JorgeMaker lets move this to the proper thread. @Owen_Williams sorry for hijacking.
Ok, so because others do not facilitate multi-axis synchronized motion, SimpleFOC shouldn’t either?
Klipper is essentially a really well written fully functional USB parser, which interpret Gcode and handle all the timings, synchronization etc. what we have to do is teach SFOC how to talk Klipper or maybe even tinker with the mainframe …