Thank you for all the input guys, will be looking in detail when Beziers
time come, but arcs will remain arcs, beziers are to smooth out point
clouds and sharp corners which are not arcs to begin with.
For phase 1.2 Joint limit pre-calculation, the joint limits, I already
did a small component that can predict if the executing gcode will reach
joint limits at gcode load time, I was thinking, this can be used to
remove the need to set AXIS limits, axis limits IMO should be inherited
from joint limits + IK, you set joint limits (they are the hardware
reality), and axis limits become derived from that through inverse
kinematics. For trivkins it's trivial, for non-trivkins the "axis
limits" concept doesn't even make sense in Cartesian terms anyway - the
reachable workspace is a complex volume depending on the pose.
I also want to implement something in the gcode, to check if a position
is reachable before actually going there. Thinking of G1.1 G2.1 G3.1 etc
as "dry run" variants of motion commands - same syntax, same path
planning through the TP and IK, but instead of commanding motion, it
returns what would happen.
Something like:
|G1.1 X100 Y50 Z-10 A30 B45 F1000 |
After execution, named parameters get set:
|#<_motion_ok> ; 1=would succeed, 0=would hit limit #<_motion_x> ; final
X position (target if ok, last safe if not) #<_motion_y> #<_motion_z>
#<_motion_a> #<_motion_b> #<_motion_c> #<_limit_joint> ; which joint hit
limit (0=none) |
The nice thing is no tolerance parameter needed - the trajectory planner
already knows the servo cycle time, so "position one cycle before
hitting limit" is inherent from how the TP works. Same code path as real
motion, runs through kinematics and limit checking, just doesn't command
the drives.
This would be useful for:
* Complex 5-axis where you want to know if a position is reachable
before committing
* Probing cycles that need to plan escape routes
* Adaptive toolpaths that make runtime decisions
* Recovery after faults
For 5-axis non-trivkins you'd get which actual joint would fail, not
some meaningless "axis" number, because the IK ran and found joint 4
would hit +175° for example.
Not sure if this fits in the TP2 scope or should be a separate PR,
wanted to get your thoughts before going further
On 1/27/2026 1:42 AM, Robert Schöftner wrote:
On Mo, 2026-01-26 at 16:29 +0100, Bertho Stultiens wrote:
On 1/26/26 4:18 PM, Robert Schöftner wrote:
you can't exactly represent conic sections like circles / arcs
Quadratic Beziers cannot represent circles or circular arcs
correctly.
However, using Cubic Beziers can (extensively used in SVG).
you are right of course, here is how to construct a circle out of cubic
beziershttps://spencermortensen.com/articles/bezier-circle/
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
