KUKA Sim Pro 3: Why Won't the Roof Part Follow the Chassis?

A roof part that sits in mid-air while the chassis rolls out from under it is not a physics problem and not a gripper problem. The conveyor is transporting components, and after the robot lets go, the roof is still its own component sitting in the world root. Nothing links the two, so nothing carries it.

Modelling the roof as a box feature on the chassis does not fix it either. Geometry you draw inside one component is not the component the robot picks and places; the placed part remains a separate object with its own position matrix in world coordinates. Get the transport running first, then make the link permanent.

Confirm What Is Actually Moving on the Conveyor

Before touching any script, prove the transport mechanism. Conveyors in KUKA.Sim move components along a path kinematically — they write a new position each simulation step to every component they have accepted. There is no friction, no contact force, and no gravity coupling to whatever is stacked on top.

1. Run the cycle and pause the simulation the instant the robot releases the roof.
2. Open the component list / hierarchy and look at where the roof sits. If it is a sibling of the chassis at world level, it will never move with it.
3. Step the simulation forward a few hundred milliseconds. If the chassis position changes and the roof position does not, the diagnosis is confirmed.

Check that proves it: chassis position matrix advances, roof position matrix is frozen. Move on.

Attach the Roof to the Chassis From Python

The clean route is the connectComponents entry in the Python API help. It joins two components through their connectors, so the roof becomes a child of the chassis and inherits every transform the conveyor applies to it. Read the entry before you type the call — confirm the argument order and whether it expects component objects or interface names in your build.

from vcScript import *

app   = getApplication()
comp  = getComponent()
sig   = comp.findBehaviour('AttachRoof')   # boolean signal from the robot program

roof_ref = None   # set this when the roof is picked, not by name

def OnSignal(signal):
  global roof_ref
  if signal.Name == 'AttachRoof' and signal.Value:
    chassis = app.findComponent('Chassis')
    if roof_ref and chassis:
      app.connectComponents(roof_ref, chassis)

1. Add a Python Script behaviour to the chassis, the cell controller, or the process component that owns the station — anywhere with a stable reference to both parts.
2. Capture the roof component object at the moment the gripper grasps it. Feeders name copies RoofPart, RoofPart#2, RoofPart#3; a name lookup will grab the wrong one on cycle two.
3. Fire the attach from the same robot output that opens the gripper, one step after the release, never before. Attaching while the tool still holds the part gives you two parents fighting over one transform.
4. Confirm in the help file whether your API version returns a status or raises on incompatible connectors, and handle that return.

Check that proves it: pause after the signal fires and confirm the roof now appears under the chassis in the hierarchy.

Keep the World Position When You Parent

Reparenting changes the frame a position matrix is measured in. The roof's matrix was expressed in world coordinates; once it hangs off the chassis, the same numbers are read as an offset from the chassis origin. If the roof jumps to the floor, to the chassis datum, or somewhere behind the conveyor the instant you attach it, that is the whole story.

Either use the API option that preserves world location, or compute the offset yourself: take the roof's world matrix, multiply by the inverse of the chassis world matrix, and write the result back as the roof's local matrix after the connect. Do this in one simulation step so no frame renders with the part in the wrong place.

Check that proves it: the roof does not visibly move at the moment of attachment, and the gap between roof and chassis stays identical from that frame onward.

Use the Process Task If Your Model Already Has One

If the chassis and roof are products flowing through process or works components rather than bare CAD blocks, do not write a script at all. Those libraries already carry an assemble/merge task that consumes the roof into the chassis product and hands the combined product back to the transport system. The task handles the parenting, the transport registration, and the statistics in one place, and it survives a simulation reset without extra code.

Decide by looking at what feeds the conveyor: if the chassis arrives as a product from a source with a process flow attached, use the task. If it is a plain component you dragged in from the eCatalog, use Python. Mixing the two — a script that reparents a part the process engine still believes it owns — is how you get a part that follows the chassis on cycle one and vanishes on cycle two.

Check that proves it: the combined chassis-plus-roof is reported as a single item at the downstream station.

Run the End-to-End Verification

1. Reset the simulation completely. Runtime parenting is not saved; a reset must restore the original hierarchy or your second run starts from a corrupted state.
2. Run three full cycles at normal speed. Every roof must ride its own chassis — watch for the second and third parts attaching to the first chassis, the classic symptom of a name-based lookup.
3. Run one cycle at 10x speed and one stepped slowly. Timing-dependent attach logic breaks under speed changes; a correct implementation is speed-independent.
4. Follow one assembly through every downstream transfer, curve, and merge. The roof must hold a constant offset from the chassis through all of them.
5. Check the part still moves after the conveyor releases it to the next device, and that it is not counted twice in any throughput statistic.
6. Save, close, reopen, and repeat step 2. Script behaviours that reference components by stale object handles fail only after a reload.

Stop here if the connect call raises an error you cannot resolve from the help file entry, if the components expose no compatible interfaces, or if the process library components behave inconsistently between versions. Those are build-specific questions about the API and the shipped catalog, and they belong with KUKA support or KUKA College through the official channel for your license rather than with another hour of trial and error.

FAQ