Calc_junction() numerical issue (stright line move)

I’ve been playing around with controlling acceleration via gcode and noticed that it seems like straight-line velocity can be limited by the square-corner-velocity code, which is unexpected since there is no corner.

I think I tracked it down to calc_junction in For straight-line motion, cos(theta) is -1. however, the code limits it to -0.99999, presumably to avoid division by zero in the subsequent calculations. That means straight-line motion is approximated as having a slight corner. If you happen to have set square-corner-velocity to a low number, this can manifest as an unexpected velocity limitation.

Here’s the relevant code:

    junction_cos_theta = max(junction_cos_theta, -0.999999)
    sin_theta_d2 = math.sqrt(0.5*(1.0-junction_cos_theta))
    R = (self.toolhead.junction_deviation * sin_theta_d2
         / (1. - sin_theta_d2))
    # Approximated circle must contact moves no further away than mid-move
    tan_theta_d2 = sin_theta_d2 / math.sqrt(0.5*(1.0+junction_cos_theta))

One possible fix is to add a condition testing for this case:

    if junction_cos_theta < -0.999999:
       # assume straight-line motion
       sin_theta_d2 = math.sqrt...
       R = (self.toolhead...


Note that there are other calculations there that shouldn’t be excluded, for example maximum extruder velocity jerk. In general, it might be worthwhile to rework the junction velocity calculation there to either assume straight line motion and skip some checks, or just add a couple of '9’s to the limit.

That said, the current limit of -0.99999 results in a maximum velocity of ~1300 * scv, so even if scv == 1 mm/sec, you’d get maximum straight line motion velocity of 1300 mm/sec. Isn’t that enough in general?

However, what I noticed is that the current move/toolhead code does not capture the current junction_deviation in a move, so if you are adjusting maximum acceleration or scv mid-moves, you may end up in a situation when a technically incorrect junction_deviation value is applied for certain moves (for a different max_accel or scv value). So, actually this might be a problem that you observed.

Hi Dmitry,
You’re probably right re 0.99999 being enough with sqv of 1. I was just surprised that sqv can limit straight-line motion at all. I’d set sqv to 0 and was seeing every straight-line move decelerate to 0 mm/sec. Then I tried sqv of 0.01 and still hit velocity limits, which surprised me.

Interesting observation re junction_deviation.

As I dig in more to adding explicit acceleration & jerk control, it seems to me there may be room to rejigger some of the code in to clarify the state variables in a Move and how they change over time and what invariants there are. That includes for example, junction_deviation.
Once I get my code working, it’d be great to get your thoughts on a changelist to show you what I’m playing with.


I see. But in reality, scv == 0.01 isn’t practical, so the On the junction_deviation, you may check out this PR (not reviewed or merged into the mainline yet).