Hi,
We are experiencing a strange and unpredictable behaviour of linear movements with blend when using new firmware versions 5.9.1 or higher. When using blend between waypoints with large orientation change (but NOT small translation as described in the release notes) the robot seems to stop completely at the waypoint instead of proceeding with the specified blend radius. At this point the tool orientation is somewhere between the start and end position. The new behaviour is significantly different from what we have seen in older versions.
So far we have not found any specific circumstances that cause this to happen, but apparently there is some difference between 5.9.1 and 5.9.4 versions again. The only safe solution to use no blend in our application.
If possible, we would like to understand the changes in more detail. It might be related to the Release Notes but the description does not mention any changes in moveL with large orientation AND large translation or define what is considered large or small.
Fixed blend algorithm for MoveL movements with large orientation change and very small translation.
Fixed issue where blending during MoveL could result in aborted program execution or the robot drifting away from the expected trajectory. The issue was related to the combination of orientation blend paths and positional blend paths. In scenarios where the required joint movements of the MoveL blend are dominated by a tool orientation change, i.e. especially relevant for zero or small tool position changes (lower than the blend radius), this issue would occur.
Has this issue been resolved with later software releases?
Hi @pho ,
After a long investigation now we are able to define when the blend issue occurs. It depends on the additional commands performed between the two move commands. In a test program we have observed that one sync() command does not affect the blend behaviour, but two sync()-s make the robot comletely stop before proceeding. Commands other than sync() for example XMLRPC calls to a daemon process have the same effect.
The strange new behaviour may be therefore a side-effect of the recent optimization that has eliminated the old error “The program used to much time without instructing the robot what to do”. Our theory is that recent firmware versions run a hidden thread that controls the robot, and it stops the robot immediately (without the above error message) if no commands are received from a user thread within a time frame.
We have tested with newer Polyscope versions and it seems to be consistent. But for us this is no longer an issue because we can avoid it by optimizing our program to reduce the number of commands performed between move-s.
Best regards,
Csaba
Hi @csaba.mucsi,
Just to clarify, this is not an issue with the blend algorithm itself. But a comment that you shall consider what you are executing in between two blending waypoints?
Ebbe
Hi @Ebbe ,
You are right, there is most likely no issue with the blend algorithm itself. The strange behaviour can be observed when additional instructions with physical time usage are executed between the blending waypoints.
Best regards,
Csaba