Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Probably not a bug. InstructionListJoints MOVE_ID oddities

First, let me say I'm happy to use your wonderful software.
However, there is some strange behaviour I've recently found working with it. I'm trying to emulate an external axis with a help of the Python API and a part of my script must collect time statistics of a robot program.
So I call it like this:
message, joint_list, status = prog.InstructionListJoints(flags=4, time_step=0.01)
# the next line is here just for the debug purpose
prog.InstructionListJoints(flags=4, save_to_file=r'Z:\VM_Shares\steps.csv', time_step=0.01)
And then I get something strange (all the next references are relative to the applied station and the spreadsheet):
 * MOVE_ID = 4 is skipped and I believe it's ok since there is no movement (in the physical sense) around it
 * MOVE_ID = 6 is skipped for the reasons unknown to me
 * Two program movements 'MoveL 27' and 'MoveL 29' are merged under the same MOVE_ID = 28
 * The final 'MoveC 30' aka 'MoveC (Target1, Target1)' has MOVE_ID = 0 instead of 31

So far I've managed to solve the issues #1,2,4. The script generates unique IDs for the movements in the joint_list and then matches them against the program movements in a cycle. If the joint positions are close enough (less than 0.001 deg) then they're considered matching.

As for the issue #3, well. While the movement is relatively short in this very example, I still can find some average position between the last matching movement and the next one in a cycle. But what if I consider accelerations or a movement will take a long time elsewhere. Maybe there is an easier way. Could you please help me with this issue?

Note: the spreadsheet's been modified by hand to find the matching program movements.

Attached Files
.rdk   Template with tcp mommy modified 2.rdk (Size: 964.03 KB / Downloads: 11)
.xlsx   steps.xlsx (Size: 153.79 KB / Downloads: 15)
Update: These issues have nothing to do with rounding. Removed the rounding instruction with the same result. The third issue marked in the spreadsheet with red font.
Update 2: Speed change instructions are involved somehow. I've checked their parameters and enabled everything: linear speed, rotational speed, and both accelerations.
Thank you for your feedback and clear explanation of the issues.
There should not be missing IDs, this used to be an issue we fixed in the last few months.

Can you update to the latest version and reproduce this issue?
Thanks for the response. Sure. I'll try it ASAP.

I'm back with some updates.

Actions taken:
1. An old version of RoboDK's been removed and the latest one (5.1.3) installed
2. The buggy station opened, then saved and reopened again
3. InstructionListJoints(flags=4, save_to_file=r'Z:\VM_Shares\steps.csv', time_step=0.01) applied

The results are likely the same.

P.s. There's an interesting thing. When I add a movement to the end of my program (MoveJ to be exact), then the final MoveC gets MOVE_ID=31 as expected. But the new MoveJ is split into 26 rows having the same joint angles and MOVE_ID=0 instead. The corresponding spreadsheet is attached in case you wish to investigate it too.

Attached Files
.xlsx   steps from 5.1.3 with an additional MoveJ.xlsx (Size: 143.26 KB / Downloads: 9)
.xlsx   steps from 5.1.3.xlsx (Size: 142.18 KB / Downloads: 11)

Users browsing this thread:
1 Guest(s)