"Axis speed exceeded" warning : can't see why

[Xylotica]

I just used the "Axis movement" component for the first time, and find that it induces an error message during execution.
I set the "Vel" input to a value of 10, which is 10% of the max speed if I understant well.

So what could be the problem ?
The message states that I am exceeding the max speed by over 600% ; this seems completely crazy...

Here's a screen capture of the pendant : https://goo.gl/photos/tgKrVTGVtCuUongj8

Cheers,

[Xylotica]

Wild guess : Since the A4 axis is involved, this was probably due to a singularity.
I broke the alignment by forcing a small A5 angle, and the problem is gone.

Cheers

[Johannes @ Robots in Architecture]

Hello,

That sounds very likely, sorry for the slightly delayed reply. Just one quick remark: According to your screenshot, he problem occurred with a LIN movement, where the speed is set in m/sec and refers to the TCP, so individual axes can go up to their maximum speed in order to achieve the tooltip speed. When you are close to a singularity, the required speeds quickly ramp up and can cause the robot to stop. With PTP movements you do not have the singularity issues and set the speed in percent, as you've mentioned.

Best,
Johannes

[singline]

Excellent! Thanks!

[Xylotica]

I get a lot of (probably valid) excess speed warnings with my LIN movements, but I'm a bit surprised because I am nowhere close of A4-A6 singularities...

I tried using PTP moves instead, but the I get occurences of wild PTP movements on approach phase of "Tool offset" commands...
[EDIT] I realized that my initial "Axis movement" imposed a negative value for A5 while the subsequent values were positive, thus the crazy "merry-go-round" movement. Problem solved.
I guess I should also start caring about the "STATUS" and "TURN" inputs.

[Johannes @ Robots in Architecture]

Hello,

The excessive speed calculates the current speed of each axis when it does a CP movement with a given speed in m/sec.
As you know, the robot often does not reach the programmed speed due to the density of the toolpath and other factors.
So something that in the ideal, digital world looks like excessive speed may not be a problem in the real world.
We are currently tuning a correction factor for that, but as anything it's just an approximation.

CP movements like LIN keep the current posture of the robot, while PTP movements need the posture to be defined.

Best,
Johannes