Something I’ve discovered during recent scripting.
The pattern above is the actual script. The pattern below is an illustration of the Handy’s movement as I’ve observed.
The pale (middle) section is too slow to be performed correctly. So the FW blended them into a single upward stroke. It also offsets the top point, resulting in a much slower downward stroke.
So, when there are action too slow to be performed, it not only causes stutter but also affects its surrounding actions. When this happens it can be detrimental to the script’s precision.
Before we figure out what the bottom speed cap is, do a lot of testing before publishing your script.
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…
Some helpful documentation over the device’s specifications. Though we need to translate the speed units into OFS’s “unit/s”.
Max output speed: 400mm/s (capped in FW)
Min speed: 32mm/s (capped in FW)
According to this post it will be 363.636 units per second. But that’s way slower than my experience. Testing with this script shows it can handle up to 480 unit/s.
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.
I dont know the firmware version i have, but noticed that there was a case where if the movement was too slow, it might skip the next node entirely.
The start is at the 0, and the next node 30s later is at 100, and 1s after that it goes to 0 again. The handy in this case stays at 0 for 31 seconds. And this is VERY common at the start of a script.
Could this be a related issue?
(the workaround is adding another node about 2 seconds before it at the top, which if it hasnt moved yet, still means a 2s movement which is fast enough to perform - but its not neat)
