[BUG] Allow junction deviation for kinematics

[tturpin]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

It seems to me that junction deviation can "work" with kinematics (delta), but it is still marked as non-supported. If it is ready, users should be allowed to enable it, as disabling classic_jerk can have some benefits.

I spent some time understanding Marlin's motion planning, and for me it looks like junction deviation can work with kinematics: since Planner::_populate_block receives a cartesian motion vector, which is used to compute the junction vector, I don't see why it should be restricted to cartesian kinematics.

I tried enabling it, with success. All I did was:

• disable the HAS_JUNCTION_DEVIATION && IS_KINEMATIC sanity check
• add DELTA to the test in the conditional for optimizing junction vector normalization:

    /**
     * On CoreXY the length of the vector [A,B] is SQRT(2) times the length of the head movement vector [X,Y].
     * So taking Z and E into account, we cannot scale to a unit vector with "inverse_millimeters".
     * => normalize the complete junction vector.
     * Elsewise, when needed JD will factor-in the E component
     */
    if (ANY(IS_CORE, MARKFORGED_XY, MARKFORGED_YX, DELTA) || esteps > 0)
      normalize_junction_vector(unit_vec);  // Normalize with XYZE components
    else
      unit_vec *= inverse_millimeters;      // Use pre-calculated (1 / SQRT(x^2 + y^2 + z^2))

As far as I can see, it just works !
I certainly don't understand every aspect of motion planning which could affect this, but if this can be generalized as much as possible by someone with more expertise, it would be great. Maybe the comment deserves more general wording too.

Note: I tagged this as a bug rather than a feature request because

• the feature looks like it's already implemented
• if it is actually supported and could be enabled (almost) for free but is not, it's somehow a bug...

I apologize if this choice is not appropriate.

Bug Timeline

It assume it was never supported

Expected behavior

No response

Actual behavior

No response

Steps to Reproduce

No response

Version of Marlin Firmware

dev-2.1.3-b3

Printer model

No response

Electronics

No response

LCD/Controller

No response

Other add-ons

No response

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

No response

[tturpin]

I found this post which indicates that junction deviation was considered likely unsuitable for delta.

I'm not convinced by the argument because, even if the rails movement is not linearly related to toolhead movement, the rationale behind junction deviation still makes sense for controling the toolhead acceleration (which may have most of the inertia).

The last post in the above thread says that it works for at least one delta user. So far, I have only tried with a simple back-and-forth movement (with success), but I intend to continue using it.

I'm starting to understand better the potential strange interaction of classic jerk with delta, and it's really a strong motivation to enable junction deviation (though it doesn't solve everything).