Maybe you can try one of my code from Robotmaster and test it.
Any advice for improving milling accuracy on older hardware?
-
neeboy74 -
December 20, 2013 at 3:18 PM -
Thread is marked as Resolved.
-
-
I have to master krc1 every time I start it up using dial gauge option, the robot is already in its mastered position but no need for KRC2.That shouldn't happen unless your KRC1 has dead batteries.
-
So...today I tried setting the "jog" function on my Kuka setup to move 100mm at each keypress. I cut a 100 mm by 200 mm rectangle, no problems whatsoever, even measured it with a carpenter's square. Distances are so-close-to-darn-near perfect, as are the angles between edges (all 90 degrees). I also jogged around it a few times AFTER cutting and it followed the same path perfectly.....I think I can infer that my robot is mastered correctly, right??Then I tried cutting squares generated in SprutCAM, and nothing but problems, squares become rectangles and the edges are noticeably not at 90 degrees to each other. I swear up and down that my measurements in the SprutCAM machine file are accurate, I had my machinist friend verify that with me. GRRRRR......
Okay. I'm not familiar with SprutCAM, but I'd say that process of elimination has brought us to the point where we need to look at the SC output that you're putting into the robot. If you generate a simple, small square cut, can you post the resultant code?
-
I can send you some code as well... can you try to make a square cut not by jogging, but with a simple code with coordinates on X, Y?
-
yeah that's the next step. may have time to try that today,otherwise maybe not for a few days.
-
Hi Neeboy74,
I have attached a SRC file.
This is for KR2210-L150 so it might not work for KR30, it was generated from RM, in my robot if I run this file the tool tip goes from X=0, y=0 --->x=616, y=0 --->x=616, y=-910 --->x=0, y=-910 and back to x=0 y=0.
I can generate the same code for KR30, but need to wait for my laptop adapter which I left it in Taiwan. -
Thanks for the continued help, everyone.
I have some family stuff I have to deal with right now for the rest of the afternoon. I may be able to post some code to this thread later today, if not then it'll be another 24 hours.
-
You could try my GeneralEllipsoid module located at kuka.skyefire.org. If nothing else, it should let you measure just how well the robot can cut a circle independently, without any possible SprutCAM-related issues.
-
Bought a 120W laptop charger my laptop is up and running.
Open attachment for the SRC file and the exe simulation.
http://i1220.photobucket.com/albums/dd459/h…ionsideview.jpg -
Hello again everyone:
It turns out I will not have the time until this weekend to refine down to a simple program or run anyone's examples; for now I'm just going to attach a program that is supposed to cut all squares (...but they end up all being rectangles)
One major discrepancy I have noticed right away when comparing my SprutCAM output to the work of others is that there is a "lot of business" at the start and end of everyone else's work, before the cutting coordinates come along. I'm just gonna throw this out there: is my SprutCAM output lacking some important info?
Back before I discovered SprutCAM, I was using Rhino/Grasshopper/PRC, and I did manage to successfully cut a simple polyline toolpath...the formatting of the file looked almost identical to what the examples of others show.
This is the only thing I can think of thus far, that something is badly lacking in the start/end of my SprutCAM code. Thanks for any help!
-
Definitely sounds like a mastering issue.
that said, no robot is excellent at cutting circles like Skyefire said, but 12" circles you should be able to do quite well. I have mastered Kuka robots quite well using standard dial gauges using the 'feel' method. It IS possible but you may have to refine it and do it multiple times, where an EMT is much, much easier.
There might be a shop near you with an EMT maybe put the feelers out
-
I just now discovered that, according to page 40 of the BEDHBSTARTUP_R41.pdf, I have NOT been calibrating the POSITION (X Y Z) of my tool...all this time I've only been calibrating the ORIENTATION of my tool (using the A B C - 2 Point" procedure).
I don't have time to physically try all this tonight, I have "work" to do....could this really be my answer? I'll give it a go tomorrow nite!
-
Simplest check for TCP dimension (as opposed to orientation) is to simply put the TCP in mid-air, and rotate in A, B, C while watching the tool tip for motion. If the tool tip holds position while rotating, your TCP XYZ is good. If not, then your TCP XYZ is bad -- how much depends on just how much the TCP moves while you're rotating.
-
I DID IT! I DID IT! I DID IT!
Yup...as I suspected, I calibrated for position...and now I program squares and I cut squares!! YAAAAAY!
-
hehe, now is the time some top notch milling stuff
-
also I noticed your sprut code has continuous positioning active, but does not set $APO.CDIS in the header of the file. I don't know what the default is, but with most kuka variables, the default is big!
Sounds like you are moving in the right direction....tcp!....its not quite like a cnc where you just load the tool and go to work!
-