I use Sprutcam to generate cam toolpaths, export SRC files, and filter them through a calibrated RoboDK cell.
I'm often unable to filter programs without a clear reason. Occasionally it works fine, occasionally it does not.
Here's an example:
I have a toolpath that is just roughing out an area. Robot drops down to the start area with a MoveJ function, then completes it with MoveL commands.
If I run this program on the robot, I have no problems. If I filter it in RoboDK first, it says "failed to filter":
The problem seems to be that in the SRC file, I have E1 called out to rotate to -52deg in the first line, then not afterward. So it brings the arm and E1 to the correct angle, but at the very first MoveL it forgets it's using a kinematic frame and wants to approach from a different angle. I tried adding {E1 -52} to the end of the failing lines, but it ignores that and still fails the first MoveL command as well as still trying to approach from the incorrect angle.
I don't know where to go from here to solve this, the code just says "failed to filter, check joint limits and singularities" which isn't the actual problem.. this works just fine for a while, until it gets an attitude. Why is it suddenly ignoring the kinematic frame? Is there any more info on what is causing the failure to filter?
I've attached my RDK file, the SRC file, and the failed filtered file. I was adjusting the angle from -48 to -52deg to try to get it to work, so they might slightly mismatch.
Here is my working R1 RDK file, running very similar files with the same header/footer. They use the same post processor to generate the SRC files.
I dug up an older SRC file that I had filtered and ran about a month ago with no issues, and now it has the same filtering error. I tried loading an older version of this RDK schema, abut I'm still getting the same errors.
For program filtering I would recommend you to output the position of your tuntable for each line of movement to avoid confusion. I believe RoboDK still uses the last value that was set, however, you'll see a lot of warning messages.
If you try importing the program as a robot program in RoboDK you can get an understanding of how RoboDK sees your program (tool used, coordinate system)... Did you properly calibrate the root point of your KUKA turntable and enter the correct coordinates in RoboDK? I believe the path and setup does not look the same as the picture you shared.
Finally, to avoid similar issues I would recommend using robot machining projects in RoboDK and loading the milling projects using APT files.
if I add the E1 values I still get the same errors:
Code:
LIN {X -376.341,Y 605.385,Z 588.740,A -163.630,B -67.791,C -107.401,E1 30.00000,S 'B010'} C_DIS ; filtered
$VEL.CP=0.167
LIN {X -376.417, Y 785.358, Z 609.959, A -163.721, B -67.766, C -107.382, E1 30} C_DIS ; ERROR: FAILED TO FILTER TARGET! Check joint limits and singularities
PTP {A1 -41.657, A2 -61.938, A3 114.295, A4 53.219, A5 35.084, A6 27.625, E1 30, E2 0, E3 0, E4 0, E5 0, E6 0} ; USING CONFIGURATION 'B010'
I was able to filter some programs that were much smaller, but 90% of my programs are failing at least at the very end (like the code snippet above).
I do have the same root point between Sprutcam, RoboDK, and the machine, the pose just looks different because I just drag the SRC files in and click "filter only" to filter the programs. Here's what it looks like on the first MoveJ command in each program:
I've tried importing them (joints poses) but the behavior is not right. RoboDK doesn't acknowledge the external kinematic or something. MoveJ 1 is in the right spot, then MoveL 2 fails, then on MoveL 3, it rotates the table (E1) to the wrong angle but keeps the base frame in the correct position... I can't attach the screencast videos so here is a google drive link to them: https://drive.google.com/drive/folders/1...drive_link
09-25-2023, 10:27 AM (This post was last modified: 09-25-2023, 10:47 AM by Albert.)
Something doesn't make sense with the location of the turntable. If we look at the XY axes of the turntable there is some discrepancy between the 2 videos you shared. The root point looks rotated around 90 degrees. How did you configure the turntable? Can you share the $config.dat and $machine.dat files of your controller?
You can find more information about using external axes with KUKA robots here: https://robodk.com/forum/Thread-How-to-c...ernal-axes
I understand the issue is mostly with entering the right information in RoboDK to properly filter KUKA SRC files.
Did you successfully filter targets using this setup in RoboDK and other programs? (programs that run on the real robot)
We are not KUKA experts when it comes to setting up external axes but we can help you troubleshoot and properly enter the location of the external axis in RoboDK.
I found that the table was rotated because when we were defining it using poses, it also give you roll/pitch/yaw values, and we need to go back and manually change those to match the cell (approximately 0,0,0).
The point we were measuring to is just arbitrarily hot-glued to the rotary table, not exactly on the X axis. Basically, it was rotated 90deg around Z.
The filtering was better when I corrected that, but it still fails in a few areas. The problem we found is that the robot's "safe" envelope for milling is very small, maybe a 18" wide x 48" tall window looking at the part. When I'm inside that window, it filters correctly.
Back to the filtering errors, is there any way I can see better why it's failing? E.g. what joint is close to a singularity, or whatever the issue is?
But how can I tell *why* they are failing to filter?
I can't load the SRC files, it doesn't behave correctly in robodk. But the filter-only option works, I can't remember exactly why but Jeremy had said this was likely the only way we could use the robodk filtering.
You can tell because when you load the program, it stops loading instructions when the robot is close to joint limits or a singularity (for example: close to axis 5 at 0 deg, or arm fully extended).
