Visual Components Vs. Kuka Sim

Dear all
This is not about Kuka Sim or anything within that Simulation software however i’ve been told countless times (by my companies Robot programmer) that the program Kuka Sim is more trustworthy when it comes to cycle times of a simulation…

As such i’ve created an identical simulation in both Visual Components 4.5 and Kuka Sim 4.0 and programmed each PTP and LIN position identical + used the same components in the entire Depalletizing task…

The results are somewhat the same, Kuka Sim comes out with a cycle time of 99 sec and VC on 104…
Now the difference could be the fact that Kuka Sim uses a % based value on Acceleration and Deceleration (also a thing my robot programmer claimed was not trustworthy in VC) where VC uses an actual value eg. 8000 as default i believe… They also claims that the robot does not slow down if it approaches the “safety zones” - a feature possible in Kuka Sim but not VC they claim.

I’ve also noticed that they both uses something called “Firmware version” in VC as of 8.6.6 and KukaSim uses “RCS V 8.6” which i suppose almost the same then…

My question is simple;
Is my colleagues statement correct, can i not trust VC over Kuka Sim when attempting to identify a cycletime of a robots operation?
PerformanceTest.vcmx (8.1 MB)

2 Likes

Generally any difference comes from different level of simulation, and difference in motion planning logic.
VC’s motion planning is “general purpose” so the real KUKA controller logic probably differs in many special cases. KUKA.Sim uses KUKA’s own robot controller simulator (RCS module), so the logic should be the same as on real robot controller, or at least very close to it.

The VC motion planning and simulation doesn’t take into account e.g. dynamics of the robot, so a robot arm with high payload will move just as fast at the extremes of its reach as same robot without any payload. I don’t know if and to what extent the KUKA’s RCS takes this into account, but it probably does, as payload can be configured in KUKA.Sim. Further details like settling time for servos might be difficult to simulate and calibrate.

If you only run robots within “comfortable” subset of they capabilities, and only use basic motions without e.g. splines, blending, singularities, controller modes optimized for speed vs. accuracy etc., then you might not see much difference between the generic motion planning in VC vs. KUKA’s own.

If you use VC 4.5 Premium with KUKA OLP add-on and the same RCS for motion control, then it should be practically identical to KUKA.Sim.

1 Like

So any VC case layout with a robot is going to get the wrong CT result, right? After all, the real-time load of the robot is not configurable.

This means VC 4.5 Premium with KUKA OLP enabled should not be any different regarding the cycle time even at ms level?

I’ve heard from a Kuka Sim expert that even this is not 100% accurate in the Simulation environment! As such you cannot 100% trust the software, after all, it is an attempt to replicate the physics and as such the amount of data required to make a true simulation is nearly impossible…

Also to reply to your post Davinci, KUKA OLP enabled is just a way of programming the robot and as such you have a more “true” feeling of the KUKA software language as you would be used to if you were working with Work Visuals (Kuka Software). But the differences in the simulations cycletime is negligible.
In short, if your cycle time is so critical that you are trying to tweak a few more % out from the simulation to reach the target, the concept of your machine should be reconsidered!

1 Like