Softmotion Tripod Z problem

Motion
tonis2
2020-03-05
2020-03-21
<< < 1 2 (Page 2 of 2)
  • gseidel

    gseidel - 2020-03-19

    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

     
  • gseidel

    gseidel - 2020-03-19

    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

     
  • gseidel

    gseidel - 2020-03-19

    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

     
  • tonis2

    tonis2 - 2020-03-19

    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.

     
  • gseidel

    gseidel - 2020-03-20

    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

     
  • tonis2

    tonis2 - 2020-03-20

    Yes i use this FB so do you suggest to reduse one by one ?

     
  • gseidel

    gseidel - 2020-03-20

    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

     
  • tonis2

    tonis2 - 2020-03-21

    Hi gseidel ,
    you are right again the problem was there.
    Thank you very very much.

     
<< < 1 2 (Page 2 of 2)

Log in to post a comment.