Actually talked with YangYang and realized this can be even simpler.
G1.1 G2.1 G3.1 just move to the last available point before hitting a
limit, and return a flag if it arrived to the desired target or not.
|G1.1 X100 Y50 Z-10 A30 B45 F1000 #<_motion_ok> ; 1=arrived at target,
0=stopped short |
That's it. No need to return coordinates, you already know where you are
from current position. The TP already calculates "one cycle before
limit" internally, this just lets it stop there gracefully instead of
throwing an error.
If it can reach the target, it moves there. If not, it moves as far as
it safely can and tells you it stopped short. You're already at a valid
safe position either way.
On 1/27/2026 7:49 AM, Luca Toniolo wrote:
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
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
