I am running a special case where I teach the robot 600 points with a time step of 0.1s between each point, totaling a cycle time of 60s. However, when ran it runs at 62.504s. The robot only goes to taught points with no intermediary actions such as grippers opening/closing, welding, and vacuum on/off. I am running the robot with joint commands and cnt100. Overall, the robot runs accurately to the taught points, but it is necessary that it can both run precisely and with the correct time. How can I make it so that the robot runs at the expected time of 60s?
Cycle Time Issues
-
intelligentrobotics -
June 3, 2024 at 8:39 PM -
Thread is Resolved
-
- Go to Best Answer
-
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.
.. 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.
-
- Best Answer
One possible cause: most FANUC controllers ITP is 8 millisecond. 0.1 seconds is 12.5 periods. The controller can't execute a half perioid motion.
600 times 4 = 2.4 seconds
that's close to the additional time you report.
Could be a coincidence still of course.
-
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.
-
intelligentrobotics
June 4, 2024 at 4:53 PM Selected a post as the best answer. -
One possible cause: most FANUC controllers ITP is 8 millisecond. 0.1 seconds is 12.5 periods. The controller can't execute a half perioid motion.
600 times 4 = 2.4 seconds
that's close to the additional time you report.
Could be a coincidence still of course.
This was it! I figured the issue came from the specific time step, I just couldn't find any information on what actually worked.