Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Bad turn config a the robot when getting a successful post.
#1
When I can get robodk to output a successful path, im getting a bad turn config at the robot.

What Ive noticed is there is a line i the posext line that if they arent the same for each line of code, it causes this issue. What does this correspond to exactly?


MOVEFLY LINEAR TO POSEXT(2669.0000, -132.4000, -61.2300, -171.4211, 118.8213, 94.6158, 5362.0000, 'T1:1 T2:-1 T3:0') ADVANCE WITH $FLY_DIST = ZONA


If every POSEXT line has the same as outlined in bold, it will run perfect. If one of those numbers changes, it stalls.
#2
what post processor are you using?
#3
Are you using the default Comau post processor?

The T1, T2 and T3 values are the turn flags for the joint values when the robot moves to the Cartesian location for that same movement. You can remove the Turn data as it will make the robot stop if the linear move does not fall within the right turn.

You probably moved the tool or the coordinate system after generating the targets/program. The turns are calculated based on the original joint values you used when you created the targets/program.

You can try this trick:
  1. Right clicking the program
  2. SelectRecalculate targets
  3. Generate the program again and try running it with your robot
This will recalculate the joint values, which will output the updated configurations/turns with your post processor.

If you can send us the RDK file we may be able to help you better.
#4
I did the recalculate targets as suggested and it said no issues were found.

Ive attached the RDK


.rdk R2_C60-03_01.rdk(Size: 20.36 MB / Downloads: 153)
#5
Did you generate the program again and try running it in the controller after recalculating the targets?

I noticed you are using a calibrated robot and it looks like you customized your post processor.

You could simply remove the Turn values. As long as you keep the first move a joint move and do Cartesian linear moves afterwards everything should work.
#6
(05-27-2022, 01:49 PM)Albert Wrote:Did you generate the program again and try running it in the controller after recalculating the targets?

I noticed you are using a calibrated robot and it looks like you customized your post processor.

You could simply remove the Turn values. As long as you keep the first move a joint move and do Cartesian linear moves afterwards everything should work.

I did generate the program again and tried running. same thing. Any time those turn values are different on each line it has this issue.

Ill look into removing the turn values and see how this plays out.
#7
Also, are you using a recent version?

I believe we used to have this issue about 1 year ago and we fixed it. This would apply to programs that were split to generate accurate program files (when a robot is calibrated).
#8
(05-27-2022, 09:12 PM)Albert Wrote:Also, are you using a recent version?

I believe we used to have this issue about 1 year ago and we fixed it. This would apply to programs that were split to generate accurate program files (when a robot is calibrated).

Looks like I'm using v5.2.2 64 bit




Users browsing this thread:
1 Guest(s)