[Karl]

I'm trying to drag a SRC program into robodk and filter it. the cell is defined and calibrated, attached here.

I set the base and tool frames to true in the post so they should add their own value for Base_Data[1] etc. I'm not sure if this is correct, I'll want to use 4 different tools once I'm up and running and Sprutcam will output Tool_Data[n], which robodk needs to account for.

# Use the Frame index instead of the pose when the index is provided

# Example: Set to True and rename your reference to "Frame 2" to use BASE_DATA[2])
BASE_INDEX = True

# Use the Tool index instead of the pose when the index is provided
# Example: Set to True and rename your tool to "Tool 3" to use TOOL_DATA[3])
TOOL_INDEX = True

None of the positions are filtered. Importing it (poses) gives me a different error, "failed to compute" etc, but the next target is 20mm away from its current pose.





Where do I go from here?

[Jeremy]

Hi Karl,

OK, I took a look at it and I think I found a very simple solution to your problem.

The issue is linked to how the .src file you are feeding RoboDK is built.
This file, and there's nothing abnormal about it, uses BASE_DATA[1] and TOOL_DATA[1].
But as it uses data saved in the controller, RDK does not know the value for those. (I know they are written in comments underneath, but a comment is a comment, it could be anything.)

Without this information, RDK can't filter the program according to the calibration.
There're 2 options here.
1 - You create the Tool and Base manually in RDK (this is what I did, and it seems to work).
2 - You comment the $BASE and $TOOL lines in the program, and you uncomment the explicit definition underneath.


Let me know if it gets you forward.
Jeremy

[Karl]

That worked, I must have something else wrong in my sprutcam cell now. The imported code has the external axis at -90 for the first half, then +90 for the second half. The filtered code has E1 at 0 the entire time.

---

There we go. If I drop the src file in and click "filter only", it pops it out just fine. I must be doing something by accident inside robodk to change the rotary axis after I import by poses.

It looks like my rotary is ~40mm off from true center, can I just measure the base again with the laser to update the tracker reference, and measure the rotary axis again? Maybe I moved it after the first measurement, it hadn't been bolted down yet.

---

Okay I updated the rotary center just through the TCP on the teach pendant and it's centered now.

But wouldn't it be better to have RoboDK declare the tool data and base data? Otherwise I need to have a different base for every tool since the TCP will be different. It seems like I'm bypassing a big chunk of the calibration filter by declaring the base and forcing it to assume it's correct.

[Karl]

Two notes on this:

I will definitely need to use base data from RoboDK rather than finding the center of the rotary with each TCP (they're always different by ~1mm), then if I need to change a tool from the collet I can swap and do a TCP calc without taking the part off the rotary table to find the center with it. It looks like my rotary frame is not calibrated, however.

2nd, I have this line in my SRC code (before filtering):
LIN {X -185.483, Y 251.952, Z 379.083, A -132.008, B -21.88, C -126.531, E1 90} C_DIS
and here's the filtered line:
LIN {X -185.450,Y 250.765,Z 378.579,A -132.037,B -21.941,C -126.423,S 'B010'} C_DIS ; filtered

I'd imagine that S 'B010' is supposed to represent my rotary at 90deg, I don't see anything about "turn flags" in the manual or in the frame parameters.

That's all for now!

[Jeremy]

Hi Karl,

I do agree that using RoboDK to find the center of your turntable using the tracker should be a better idea.

For the filtering, we should take a look together.
I'm sending you an email.

Jeremy

[Karl]

去t part of this. The imported SRC file can't have a $ in front of the base and tool data.
correct import:
BASE=BASE_DATA[1]
工具= TOOL_DATA [3]

This makes roboDK fill in the data according to Frame 1 and Tool 1 defined in roboDK.

Still having a problem with the S 'B010' instead of E1 90 in my code, it seems like it's using a different post processor but everything is set to KRC2. (through program>add/edit post as well as the Frame 1 parameters, post changed from Generic to Kuka)

[Karl]

Through a chat with Jeremy I learned the S B010 is a status, not the external position at all. It works to synchronize the axis to get the E1 output, but then the poses are all screwed up.

My system (sprutcam) is basically using a 6+1 axis cell, the rotary frame isn't rotating a coordinate system on my robot, it's a fixed point and the tool can rotate around it.

在这一点上我想我需要一个6 + 1同步.