I did some experiement and think this still has something to do with minimum speed. Most likely caused by the pale section in the middle which is too slow. Though I didn’t expect the FM will alter the movement in such a way that it affects the commencing downward stroke.
All three patterns has a downward stroke of 450 unit/s.
Pattern A has an upward stroke of 58 unit/s and is performed as-is.
Pattern B has an upward stroke of 90 unit/s followed by a stroke of 35 unit/s. These two strokes are combined into a single upward stroke, and the downward stroke is executed early at a drastically slower speed.
Pattern C, curiously, bypassed the optimisation and is performed as is.
I think what I learnt today is that vibrations can also be used to script slow movement that would otherwise performed incorrectly on the machine…
Sometimes with scripts, extra points like in your first pic can cause a complete stop, followed by a jerky situation/stroke after that, so I end up simplifying a lot of scripts on my own end. Using wired gigabit internet… still get a lot of unsmoothness.
Just a broader issue that I have with “detailed” scripts - they’re not smooth or comfortable to use usually.
Something like this for example is really uncomfortable to use:
Good research! We are rewriting the whole motor driver and adding predictive model regulation (MPC). The result is much more accurate script playback. I think there will still be issues when the script has high frequent motion outside the speed range (32-400mm/s theoretically and 32-350ish practically due to acceleration). Need to test more when we are closer to release. Alpha is hopefully out before summer.