KRC4 Pose Mismatch: Separate Timing from Frame Errors

A KRC4 pose that appears correct on the first loop and different on the next is often blamed on a tool offset being applied twice. That explanation is possible, but it is not the starting assumption. Robot position values are shaped by execution timing, path approximation, active tool and base data, commanded-versus-measured semantics, and the coordinate representation used at the comparison point.

A useful diagnosis freezes timing and reference frames before anyone changes mastering or persistent calibration.

Protect the known-good reference first

Save a complete controller archive and record the KSS version, robot model, mastering status, active tool, active base, load data, operating mode, override, and program line where the mismatch is observed. Capture the exact values on the first and second iterations. A screenshot without the active frame and sampling event is incomplete evidence.

Do not recalibrate the tool or base to make one reported value look right. A compensating frame can hide a timing or transformation mistake and then shift every healthy program that uses the same data. Compare the suspect program with the archived reference and identify any changes to inline forms, subroutines, interrupts, background logic, or PLC handshakes.

Relevant controller components can be reviewed in PLC & PAC Systems, while servo and axis hardware fall under Drives & Motion Control. Hardware replacement, however, should come only after the software and measurement evidence excludes frame and timing causes.

Reproduce the mismatch at a controlled point

Run at reduced speed under the site’s robot safety procedure. If the process permits, remove approximation around the suspect capture and insert a deliberate synchronization point using the behavior documented for the installed KSS release. Log one sample only after the robot reaches a defined state. Repeat from the same start pose so the two traces are comparable.

The test should answer four questions: Was the same program line sampled? Was the physical robot at the same phase of motion? Were the same tool and base active? Did the value represent commanded or measured position? If any answer is unknown, a numeric difference does not yet prove a geometric error.

Why advance run can change the evidence

KRL prepares upcoming motion instructions in advance so the controller can blend paths and avoid unnecessary stops. That look-ahead is fundamental to smooth robot motion, but it means program interpretation and physical motion are not always at the same instruction boundary. A non-motion assignment may be evaluated while the robot is still executing an earlier move.

Approximation makes this more visible. The robot can pass near a programmed point without stopping at it, so a measured position captured by a PLC scan or background task may correspond to a different point on the blended path than the programmer expects. If the mismatch disappears when approximation is removed and execution is synchronized, investigate sampling and program flow before calibration.

A production solution should preserve the desired blended path. Do not leave every point exact merely to simplify logging. Instead, define a handshake that identifies when a data sample is valid and use controller behavior appropriate to the installed software version.

Make the frame chain explicit

A robot pose is meaningful only with its reference frame. Write down the transformation chain from world or robot root through the selected base and from the flange through the selected tool to the process point. Then identify whether the reported value describes the flange, tool center point, commanded path, or measured position.

Search the program and related tasks for changes to tool, base, or frame data between iterations. An inline form, subroutine, interrupt, or background process can select different data without an obvious change in the local motion block. Indirect references deserve particular attention because the displayed variable name may remain constant while the selected index changes.

Compare all values in one declared frame. Subtracting a world-referenced pose from a base-referenced pose produces a plausible-looking but meaningless error. Likewise, applying a tool transformation to a pose that already represents the tool center point can resemble a double offset. Show each transformation step and its direction rather than compressing the calculation into one expression.

Do not confuse Euler angles with physical orientation

Industrial robot interfaces commonly express orientation with three angles. Those values are a representation of orientation, not independent physical axes. Different angle sets can describe the same physical orientation, and values can change sharply near a representation singularity even when the tool rotates only slightly.

For diagnosis, compare transformations or an appropriate orientation-error measure rather than subtracting displayed angles component by component. Normalize angles consistently and keep units explicit. If translation is stable but angle values jump, inspect representation and frame selection before blaming mastering.

Separate commanded and measured position

Commanded position describes the controller’s path target or interpolation state. Measured position reflects encoder feedback and therefore includes following error, compliance, payload effects, settling, and the moment of acquisition. Both are useful, but they answer different questions.

Record commanded and measured values together with velocity, program state, and a monotonically changing sample number. If the difference grows only during acceleration and collapses after settling, the evidence points toward normal or abnormal following behavior rather than a persistent frame error. If both are displaced by the same constant transform, examine tool and base data.

Build an atomic robot-to-PLC data contract

A PLC can easily combine coordinates from different robot interpolation cycles if each value is read independently. The robot should copy the complete pose and its context into a stable transfer structure, then change a sequence number or valid flag only after the copy is complete. The PLC reads the entire structure, confirms the sequence is unchanged, and acknowledges that sample.

Include the tool number, base number, commanded-or-measured designation, coordinate frame, units, robot mode, and sample timestamp or cycle counter. The receiving logic should reject stale, incomplete, or unexpected-context data. This turns a vague pose mismatch into a traceable interface fault.

Use simulation as a controlled comparison

KUKA’s official simulation environment supports offline validation of robot motion and application behavior. A simulation can help reproduce the program sequence, inspect frame use, and compare approximated with exact paths without consuming production time. It does not replace checks of mastering, load, compliance, encoder feedback, or real PLC timing, so treat simulation as one evidence source.

A fault-first decision sequence

If synchronization fixes the mismatch

Correct the sampling contract, approximation assumptions, or program-flow timing. Preserve the validated production path and document the event that makes a pose valid.

If the error follows a tool or base selection

Correct the selection logic or transformation direction. Recalibrate only when independent physical checks show that the stored frame itself is wrong.

If commanded and measured data diverge under motion

Investigate payload data, mechanics, servo condition, following error, and acquisition timing. Do not hide the evidence with a coordinate offset.

The strongest editorial conclusion is methodological: pose mismatch is an evidence problem before it is a calibration problem. Freeze the execution point, declare every frame, compare like with like, and change persistent robot data only after the timing and transformation hypotheses have been tested.