This happens only in manual moving, in cartesian ?
What if move the axis rotating each one, still same shaking? How many working hours has your robot ?
Have you made changes in machine.dat parameters ? I could suspect some parameters in machine.dat that could make one or more axis to pulse if they are not well setted.
I have same robot type KR210 KRC2 ed 2005 from 2007 and I can send you my machine.dat file to compare my values with yours.
I think is the simplest way to check if any parameter is the cause.
If you change something note the old values just in case you need to put it back.
give me an e-mail and I'll send you my machine.dat for comparison.
At 15 k working hours I dont think to be a mechanical problem with any gearbox.
are you sure your loads are correct? are you sure your programs are using them?
[size=2]LOAD (for the robot) is information about ANYTHING you added to it. whatever you attach to robot arm is more load.(tool, cables, junction boxes, material feeder, brackets, valve banks... ANYTHING)
if you mount tool at the end of the arm - that is load (it has weight, center of gravity, inertia etc.).
such info must be communicated to robot, it is part of commissioning process.
jumping at programming (without doing proper commissioning) is a good way to punish and wear out robot... [/size]
[size=2]it will do millions of cycles stressing entire system (motors, cables, drives...). 
[/size]
and it is not enough to specify loads... they need to be actively selected and used in programs.
otherwise robot will think it is using wrong payload (which is at least what robot is rated for, sometimes more).
one client used KR2150 to do some arcwelding... did not specify load and within a year they actually had failure (after many fault messages).
robot was thinking that it was supposed to use default payload while weaving (mig torch was maybe 1kg, robot was assuming 175kg on flange and another 50kg on A3).
what software you use for the offline programming?
Can you share some sample code - the first 10-15 lines of one of the files?
you can compare current MADA with clean copy on D:\
you can check if robot is positionally accurate ("absolut vermessen" sticker next to robot nameplate) and if this is active (hmi, robot info)
there may be additional controllers active (elasticity etc.) but to check or deactivate those you need to contact Kuka
is the robot mounted properly? is the base solid? i have seen robots pulling bolts from floor...
From experience, I know that Abs-Acc only works for robots running at least 50% (more like 75%) of their rated load. Part of the issue is simply that AA calibration is done in the factory using a nearly maximum payload, and the further your actual payload is from the calibration payload, the less precise the corrective math becomes. And even without AA, running a robot so far under its rated load can still give the gravity compensation fits.
The root issue here is that no one really has a reliable model for all the ways that a load effects the robot's accuracy, across wide ranges of loads and distances. This is a problem that has been keeping a lot of researchers busy for a long time, without a satisfactory practical answer. The best results so far that I've seen have been from New River Kinematics' SARCA module, which gets its performance by building a volumetric correction table across the robot's working volume, calibrating in the actual working conditions with the actual working payload. But I've never seen anyone come up with a predictive model that works -- the working solutions all depend on individually calibrating the robot under working conditions.
I do have one quick suggestion: try turning AA off. It sounds counterintuitive, but under conditions like this, AA can actually have negative effects.
Whoops. Lost track of the discussion -- I thought you did have AA. Well, so much for that theory.
Setting a negative value into the M element of $LOAD causes the robot to assume "default load", which is rated maximum. If you look at the LOAD_DATA array in $CONFIG.DAT, any entries that have an M of -1 are still at the factory default. Which is one of the reasons that setting correct load data on a Kukabot will generally make it go faster -- if you use the default loads, the robot assumes it's carrying its max payload, and de-rates all motions accordingly.
PID tuning of servo parameters can be done, but normally only for external axes -- the settings for the arm are not editable (or rather, you can edit the file, but the changes will be overwritten by the "correct" data when you save). But since KMCs exist, it should be possible to unlock those settings -- you'll just have to get KUKA to tell you that, and acknowledge that you're voiding whatever warranties this robot might still have.
The big issue, though, is that tuning individual servos is only a small part of the overall problem. Tuning the Cartesian motion model is... mathematically hellacious.
One thing that I think might potentially be helpful: make an O-Scope trace of the robot's position and velocity while this "shaky" motion is happening. The O-scope is one of the KRC2's greatest features when trying to deal with issues like this, and I wish every robot manufacturer would add it.
...
Which is one of the reasons that setting correct load data on a Kukabot will generally make it go faster -- if you use the default loads, the robot assumes it's carrying its max payload, and de-rates all motions accordingly.
...
Long time ago I had a robot that was faster with maximum load than with correct load! 
He moved nearly exclusively in Axis 1, the gripper was symmetric and perpendicular under Axis 6, Axis 6 looked straight down to the floor. Kuka Hotline told me to switch off the optimization.
