Hi Kamal
Is the Kuka system to run separate from the Bolt?
If you want to program Kuka in Maya then you will be using the Mimic plugin.
Mimic has a Slack group which is probably the best place to find out more about that.
Aside from using Mimic you can also program Kuka directly using an external program such as Mantis which connects to RSI in Kuka. You will need to pm me if you want to know more about that.
Gerald
Hi Ilim Aisayev
If you generate moves in Mimic and run them with R2A, then that is time-based, and they should stay in sync. So use the method of waiting for input on both machines...
Eventually they might drift... but as pm says - test...
Hi. Yes I went through Kuka originally and they first sent a software patch, which did not solve the issue, then eventually said to buy a new motor - but with no guarantee it would fix the problem.. 
But there is nothing wrong with the motor - both A5 and A6 have the identical motor and both are afflicted to some extent. Seems unlikely they would both be faulty...
Perhaps I will try running the standard version of the robot as you suggest....
PS Nearly 2 years on - I heard another user who reported the same problem from an identical model. Seems it is endemic to this Samsung branded Kuka KR10 R1420... something is wrong with the combination of servo motor and drive. I still use the robot, but with work arounds.
BTW KR10 R1100 has the same wrist motors and mechanics.
Common practice in many situations is to minimise the importance of unusual noises - unless if produces a demonstrable problem. Let us know what transpires...
In my case they first asked me to check if the brakes were ok - which they were.
I think in trace you can tell if the brake is activating?
Sorry I can't advise on the gain settings specifics. Kuka provided me with a custom program to tweak them, and I'm not supposed to share that - and besides it was for a slightly different model than yours so the actual numbers will be different to start with. But as I mentioned - in the end it didn't help much anyway...
There may be other reasons they allow a certain amount of "clearance" in the gears, but I'm not privy to that. I can only speculate it might be better for wear at high speed?
Maybe check yours first and see if you also have any backlash? If you remove the belt from the final drive of A5 or A6, then try turning the output pulleys by hand and feel if they click or not.
If you are still under warranty then certainly, you should involve Kuka first. Be prepared for a long process. The local guys here didn't know much about it, and it took a lot of explaining and recording of evidence to get it recognised, then I had to wait for enquiries made to Germany.
I had this problem with a KR10 which was also as new, like yours, it also clicked on direction change and would often click constantly like a clock at when at rest. There was also an associated problem of a slight delay when the axis was first commanded to move.
I went through a long slow back and forth with Kuka who tried changing some servo gain settings, but to no avail. In the end they recommended I replace the motors completely at considerable expense. I was reticent to do that since the robot was virtually unused and I couldn't spend that amount anyway.
Eventually I got sick of the noise and figured out how to remove the motors on A5 and A6. I found they had backlash in the bevel gear attached to the motor. I don't know how much play they are supposed to have, but it did seem to me this could not be helpful. So I machined the gear flanges very slightly to reduce the backlash and now the noise is much diminished.
Only occasionally now there is a click on direction change, but much less noticeable. A4 still clicks on direction change - I was not able to work out how to get to that one - perhaps leave it for a rainy day... In my view the motors on these axes are probably too small for the job. They work well at high speed but are less stable at very low speed. In fact Kuka made an excuse that the robot is designed for highspeed not for low speed... But I did not see that in the brochure..
I wonder though, If a move is not part of a spline block - for example just a lone simple PTP, and not part of a sequence, will the movement be any different if SPTP is used instead?
Yes it's relatively recent but not quite recent enough - the warranty lapsed late last year. At the time I bought it it had not even been put into service but had been sitting around and most of the warranty period was over. Unfortunately it has taken quite a while to discover and analyse the problem...
New update m-the saga never ends, After ongoing lengthy consultation with Kuka they advise to replace the motor assembly. The cost would be USD $4,300 including fitting. Not exactly trivial for me.
So I have taken a punt and removed the side cover to investigate deeper. What I have found is that the motor has some backlash on the output pulley which drives the belt. I compared it with the A5 motor which is identical. That motor has no backlash.
So at this point I am tempted to believe the backlash could be the main problem. Disappointing for an as new robot. Perhaps it was assembled on a Monday?
The output pulley is driven by a small bevel gear so it should be possible to adjust the shimming to reduce the backlash. I have worked with Ducati motorcycle engines in the past, and they have the same type of bevel gear for operating the cam shaft.
So fingers crossed - I may be able to save myself a lot of expense...
Thanks for your report Arthur.
It is taken for granted the last received IPOC has to be echoed in each new message.
Besides responding in time, consistency of timing response is also important for smooth control. For that reason I chose a fast Arduino to run my code, as it is not influenced by any parallel or background functions like in a PC...
Interesting - I had though spline moves were more concerned with following a path, rather than a time factor. I will revisit them..
As far as I know, you can only do this effectively using RSI or Ready2Animate - both add-ons to Kuka. With RSI you need to generate your own move path and speed profile, either programmed in Work visual, or input in real time from an external source. With R2A you must create .emily move files, for instance with Maya Mimic, then run in the robot. Also look at RoboDK... that might be the least expensive option.
Win10 has changed a few things of late. For instance you use a pin number to log on and the OS does not have workgroups. I read somewhere that might change things for networks. So far I have searched the internet and tried all kinds of things to no avail. I can access another older Win7 machine, but not the Kuka KRC4. If anyone else is using the same WIndows10 version and has successfully connected to the Kuka network using Windows sharing - then it would be nice to know what the procedure is...
It must be this version, using a pin number log on - otherwise it's apples and oranges...
Mmmm. "Should" is the word. I set up some shared folders on the robot, and I was able to access them from an older computer, but not on my current one. It may be because the new PC has Win10 home, which I'm informed has some network limitations.
Whereas C3 connects easily on both PC's...
I'll support that - even pay for it if it helps. 
I have found problems with sharing files using Windows networking,. Sometimes it works sometimes it doesn't. But your app just connected easily with little fuss...
My impression is that it does not cause issues for most industrial applications, or is just not noticed. Using robots for moving cameras is actually more critical in some aspects. That may explain the lack of other reports?
BTW it is not completely resolved - just a slight improvement unfortunately...
Hi Dmitry
It's nice to change program files so easily...
But an extra feature that I would find really useful, is ability to upload files to different folders. For example I frequently need to upload config files for my RSI program. These are in the folder Roboter\config\user\common\sensorinterface. At present I have to do it the slow way via USB.
Thanks Gerald
Well done for spotting that. Something I have never come across or imagined might happen. At least we know there's nothing wrong with the theory - just to be careful about the implementation...
