[j_cso]

In the attached collision_test_scene.rdk, I have a bunch of cartesian targets that are all children of the box_frame reference frame. And then the test_program program does a MoveJ to each of them. So I can change box_frame and all the targets move as expected, and this all works fine when I change box_frame. So far so good.

After moving the box_frame reference frame, if I right click "Target 5" and change it to a joint target, the location jumps back to the original position of Target 5. So it appears you're storing both cartesian and joint poses in each target, but not updating the joint poses when the targets get moved when a parent reference frame changes. I'm guessing you'll say that's working as intended, and that if I want them to match, I need to "Move to target" and then "Teach current position" for every target?

The reason I noticed this is that the Universal Robots postprocessor's implementation of MoveJ only ever looks at the joint pose. So I can move box_frame all I want, and the toolpath changes as expected in robodk, but it always generates the same URScript .script file as if I never moved box_frame. So the robot ends up doing something very different from what I see on screen. And that seems pretty clearly like a bug.

[Sam]

RoboDK stores the joint values in cartesian targets as reference for the preferred joint configuration.
They are not automatically updated.

In RoboDK:

• Right-click Program -> Recalculate targets.
  

With the API:

• prog.setParam('RecalculateTargets')
  

You can refer to these other posts if needed:

• //www.sinclairbody.com/forum/search.php?acti...order=desc
  

[j_cso]

Thanks Sam. Yeah I thought Recalculate Targets would do that, but it doesn't for me:

Open collision_test_scene.rdk
"Target 5"... Options and observe robot joints
"box_frame"... Options and change rotation about Z from 0 to 20 deg
"test_program"... Recalculate Targets. Targets visually move as expected, but the displayed "Robot joints" don't change
Verify this by setting "Target 5"... "Joint Target" and observe that Target 5 is now displayed back at its original spot.

[Albert]

If you need to have the correct joint values recalculated when you generate a program you should activate this option:

1. Select Tools-Options
   
2. Select the Program
   
3. Activate the option Recalculate Targets before generation
   

Let us know if this works better.

Also, the default post processor called "Universal Robots" should move to the joint target given the absolute joints by default. If you use the URP version of the post processor (Universal Robots URP), the URP file will move to the pose instead of the joints.

[j_cso]

I don't see a "Tools... Options... Program... Recalculate Targets Before Generation" option (also checked all the other Tools... Options tabs) in v5.4.3 (64bit linux).

Weirdly, Recalculate Targets is working now even though I can't find anything that's changed. But now I'm seeing failure to update here:


1: Open collision_test_scene.rdk

2:

Code:

>>> t = rdk.Item('Target 5')
>>> t.Joints()
Matrix: (6, 1)
[[ 64.011 ],
[ -123.779 ],
[ -112.164 ],
[ -34.057 ],
[ 90.000 ],
[ 64.011 ]]

3: "box_frame"... Options and change rotation about Z from 0 to 20 deg

4:

Code:

>>> t.Joints()
Matrix: (6, 1)
[[77.256],
[ -139.139 ],
[ -80.559 ],
[ -50.302 ],
[ 90.000 ],
[ 57.256 ]]

5. Right click "Target 5"... Options. Joints show the old(!) value (first joint is 64 instead of 77).


6. Right click "Target 5"... Joint Target. Target 5 jumps to old joint value, and querying t.Joints() likewise returns the old value (64).

So robodk appears to be keeping target joint data in multiple places and then failing to update some of them. I'm guessing that the stale joints are saved in the GUI element for Joint 5.

[Albert]

This option should be available with the latest versions of Windows, Linux and Mac. It was added recently. (in the last few months). Recalculation of the joints happens if there is a valid solution for the pose required. This is calculated using the active tool and reference frame.

See the image attached were to find this option in the Program tab.


Let us know if you still have issues with the joint recalculation options.

[j_cso]

Thanks, I got confused between versions. On RoboDK v5.5.2.22919 (2022-11-12) I cannot get targets to recalculate using ANY method: Recalculate Targets context menu, setParam('RecalculateTargets'), and setting "Recalculate targets before generation" followed by "Generate robot program as...". Target 5 stays stubbornly exactly where it started.

So this appears to be a regression. If I go back to v5.4.3.22250 (2022-06-27), just changing the reference frame shows the joints changing in the API (but not the GUI) as I described in my last post. If I do "Recalculate Targets" then both the GUI and API are correct. If I do setParam('RecalculateTargets') then the GUI doesn't always update but doesn't seem to revert to stale values.

So the older version mostly works right, but the current version won't recalculate at all.

[j_cso]

Have you been able to confirm? Looks to me like current RoboDK is broken for recalculating targets, while older versions worked correctly.

[Sam]

I was able to reproduce, we will provide a fix as soon as possible.

In the meantime, you can use this script to update the joint values of cartesian targets:

Code:

from robodk import robolink
RDK = robolink.Robolink()

for target in RDK.ItemList(robolink.ITEM_TYPE_TARGET):
target.setParam('Recalculate')

[Albert]

A small correction: the temporary fix should be to call "Recalculate" on each target:

Code:

for target in RDK.ItemList(robolink.ITEM_TYPE_TARGET):
target.setParam('Recalculate')

Or you can also trigger RecalculateTargets for each program (note the difference in plural):

Code:

for prog in RDK.ItemList(robolink.ITEM_TYPE_PROGRAM):
prog.setParam('RecalculateTargets')