Cycle Time Issues

What's the distance between the positions?

Think that there are some movements that can't be done in 0.1s, so you have to change motions or robot. Or you can try to change to cycle time priority in controlled start.

Quote from intelligentrobotics

.. and cnt100. Overall, the robot runs accurately to the taught points, but it is necessary that it can both run precisely..

? ? When you use cnt100 normally robot doesn't reach the positions exactly.

There's also the issue of how the motion is being measured. If the robot is starting from a dead stop, and ending at a dead stop, then that accel/decel time is going to add directly into the planned 60sec. Not 2.5sec worth, but when we're measuring in 100ms increments, the effect probably will be noticeable. I would recommend a "run in" and "run out" addition to the path that lets the robot enter and exit the time-critical path at the correct speed, and keeps the start/stop ramps completely outside of time-critical path.

How fast is the robot actually moving? What payload is it carrying, and is the payload set properly? How complex is this path? When the commanded motion conflicts with the robot's physical capabilities, the physical wins out. Trying to do a hairpin turn in 100ms probably isn't going to work. If the payload data is not set correctly, the robot's accel/decel settings will probably be wrong.

There's also a basic motion problem inherent to all robots. Unlike CNC machines, robots generally don't do well with large numbers of motion points spaced closely together (in space or time). Robot motion planners are optimized more towards widely-spaced motions, with more freedom to "fill in" the motion between the defined points. It's possible that with too many points on your path, too closely spaced, the look-ahead path planning (which can only "look" ahead a certain number of motion commands) may not be able to see far enough (in space or time terms) to achieve the velocity you want. So it's making its best effort.