thanks a lot for the photos. Given that the lengths are correct we need to find the reason why the tcp moved down by only 5 mm when moving the first axis by 20°. I expected almost 20 mm. Furthermore, the movement of the TCP in x-direction seems to match the expectation quite accurately.
Could you please repeat the same experiment, but this time move the first axis to -20° instead of +20°?
I would expect an x-movement in the opposite direction (+78 mm) and a z-movement upwards by 9.5 mm.
Georg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I have an idea what could be the problem: the order of the drives in the axis group editor.
Say your drives are named like in the photo "AxisName.jpg" I attached, could you please give the order in the axis group editor as shown in "AxisOrder_Editor.png"?
I investigated further, what seems to be the problem is the direction of rotation of the axes.
Please change the direction in the scaling/mapping settings of the SoftMotion drives, so that moving the axes in positive direction will turn the upper arms upwards, not downwards. (This information is missing from the documentation of Kin_Tripod_Rotary.)
Also, it seems that the documentation of the machine coordinate system of Kin_Tripod_Rotary is wrong: The z-axis is pointing upwards, not downwards. (The z-axis seems to be mirrored.)
Georg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes that was the problem . Just one click any everything works fine. Thank you so so so so much. I have also now an other issue check the video but i believe this is my programming fault.
In your video, did you just jog downwards in z-direction? That is, the movement that goes up again should not happen?
If you use SMC_GroupJog, effects like this may happen if the velocity/acceleration/jerk of the virtual axes used for jogging are too high. Then the robot cannot follow and as a result may leave the straight path.
Georg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you can check whether this is the problem by tracing the output MC_GroupReadStatus.InSync. If the robot can follow the jogging movement of the virtual axes, then this output is TRUE. If it changes to FALSE it means that the robot cannot follow.
Judging from the video, probable the deceleration or the jerk of the virtual axes is too high. (Do you use ramp type "quadratic" for the virtual axes? I would recommend it, otherwise the jerk is unlimited.)
You could also trace the velocity, acceleration and jerk of your real drives (variables <drive>.fSetVelocity, fSetAcceleration, fSetJerk), then you can see which value is at its configured limit when InSync changes to FALSE.</drive>
Georg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here you are . The motors have 120o distance . It's a classic delta robot...
Hi tonis2,
thanks a lot for the photos. Given that the lengths are correct we need to find the reason why the tcp moved down by only 5 mm when moving the first axis by 20°. I expected almost 20 mm. Furthermore, the movement of the TCP in x-direction seems to match the expectation quite accurately.
Could you please repeat the same experiment, but this time move the first axis to -20° instead of +20°?
I would expect an x-movement in the opposite direction (+78 mm) and a z-movement upwards by 9.5 mm.
Georg
Hi tonis2,
I think I have an idea what could be the problem: the order of the drives in the axis group editor.
Say your drives are named like in the photo "AxisName.jpg" I attached, could you please give the order in the axis group editor as shown in "AxisOrder_Editor.png"?
Georg
Hi tonis2,
I investigated further, what seems to be the problem is the direction of rotation of the axes.
Please change the direction in the scaling/mapping settings of the SoftMotion drives, so that moving the axes in positive direction will turn the upper arms upwards, not downwards. (This information is missing from the documentation of Kin_Tripod_Rotary.)
Also, it seems that the documentation of the machine coordinate system of Kin_Tripod_Rotary is wrong: The z-axis is pointing upwards, not downwards. (The z-axis seems to be mirrored.)
Georg
Yes that was the problem . Just one click any everything works fine. Thank you so so so so much. I have also now an other issue check the video but i believe this is my programming fault.
Hi tonis2,
good, I'm glad we found the problem!
In your video, did you just jog downwards in z-direction? That is, the movement that goes up again should not happen?
If you use SMC_GroupJog, effects like this may happen if the velocity/acceleration/jerk of the virtual axes used for jogging are too high. Then the robot cannot follow and as a result may leave the straight path.
Georg
Yes i use this FB so do you suggest to reduse one by one ?
Hi tonis2,
you can check whether this is the problem by tracing the output MC_GroupReadStatus.InSync. If the robot can follow the jogging movement of the virtual axes, then this output is TRUE. If it changes to FALSE it means that the robot cannot follow.
Judging from the video, probable the deceleration or the jerk of the virtual axes is too high. (Do you use ramp type "quadratic" for the virtual axes? I would recommend it, otherwise the jerk is unlimited.)
You could also trace the velocity, acceleration and jerk of your real drives (variables <drive>.fSetVelocity, fSetAcceleration, fSetJerk), then you can see which value is at its configured limit when InSync changes to FALSE.</drive>
Georg
Hi gseidel ,
you are right again the problem was there.
Thank you very very much.