Overlapping comparisons always evaluate to true

[BsAtHome]

Adding the S-curve trajectory planner with jerk limiting (#3683) introduced a rather interesting warning that definitely points towards an error in the code.

In emc/tp/tp.c line 2475 there is a comparison like:

  if (cos_theta > min_cos_theta && (maxjerk > 0 || maxjerk < 99999)) {
...
  }

Resulting in (using clang 21):

emc/tp/tp.c:2475 col 55: warning: overlapping comparisons always evaluate to true [-Wtautological-overlap-compare]

The problem is that the maxjerk comparison is always true. When it is less than 0, then it is also less than 99999. When it is more than 99999 then it is also larger than 0.

My guess is that it was meant to determine the condition 0 < maxjerk < 99999, but that is not what the code does. If so, then the || should be &&. However, that also begs the question what the real boundary values of maxjerk are and what happens when you are outside the seemingly arbitrary values of 0 and 99999.

[Sigma1912]

@grandixximo

[grandixximo]

This was YangYang's Idea, in his opinion jerk of 0 would create no motion, so instead of that we turn off the calcualtions.
A jerk over 10000k is practically equal to not having jerk, so why waste resources, just use original planner, it is basically the same. That was the thinking, i think 1Million would be more reasonable, will discuss with him, probably clean this up.

[mika4128]

yes, it's bug. this need remove. At that moment i want if jerk too big then use old tp. but this never happened.

[rmu75]

This max jerk cutoff limit really should depend on max acceleration of the machine and maybe on the servo period.

max jerk is bounded implicitely by max acceleration times 2 over servo period anyways (ignoring the cubic output resampler which smears things a bit). Max allowed jerk by the s-curve speed profile should be a fraction of that that is not too small. Nico suggested something like 5 - 10 servo periods to reach full acceleration should be reasonable.