On KUKA KRC4 controllers running KSS 8.2 or 8.3, programmers occasionally observe $POS_ACT reporting roughly twice the intended tool A-offset after the first loop iteration of a motion routine. The robot did not physically jump; the Advance Run Pointer continued into subsequent instructions while $POS_ACT still reflected a commanded, tool-and-base-dependent pose that no longer matched the measurement the programmer expected to log or to use as a frame reference.

$POS_ACT is the commanded actual position in the sense of the controller’s programmed pose, transformed through the active tool and base. It is therefore sensitive to when the interpreter advances. $POS_ACT_MES is the measured position from the robot’s feedback path and is the safer variable when you need the physical pose at a synchronization point. Confusing the two produces “double offset” symptoms that look like a tool calibration error after the first cycle, especially when an A-axis tool offset is applied inside a loop that the advance run has already partially evaluated.

Advance Run Pointer as the mechanism

KUKA’s advance run executes upcoming statements before the robot reaches the exact end of the current motion. That prefetch is essential for path blending, but it means assignments and frame math that read $POS_ACT can fire earlier than the human mental model of “when we arrive.” On the first iteration, timing may coincidentally look correct. On the second iteration, an offset applied relative to a prematurely read $POS_ACT can stack with the tool transform and present as approximately 2× the A-offset component in displays or traces.

Corrective techniques

• Insert WAIT SEC 0 at the synchronization point where you must freeze advance run before reading or writing pose-related data.
• Call BAS(#INITMOV,0) when re-initializing motion parameters so subsequent moves start from a clean basing state rather than inheriting a half-evaluated context.
• Set $ADVANCE=0 in sections that perform critical pose capture, tool offset math, or loop-carried frame updates; restore a nonzero advance later for production throughput.
• Prefer $POS_ACT_MES when the application needs the measured Cartesian pose rather than the commanded pointer-dependent value.

; Example synchronization pattern (conceptual)
$ADVANCE=0
WAIT SEC 0
; Now capture measured pose
DECL FRAME MySnap
MySnap = $POS_ACT_MES
BAS(#INITMOV,0)
; Restore advance for blending as required by the cell
$ADVANCE=3

Diagnostic sequence

1. Record $POS_ACT and $POS_ACT_MES at the same program line on iteration 1 and iteration 2 of the failing loop.
2. Confirm active tool and base numbers did not change between iterations.
3. Temporarily set $ADVANCE=0 and retest; if the double A-offset disappears, advance run interaction is confirmed.
4. Replace pose reads used for offset math with $POS_ACT_MES or guard them with WAIT SEC 0.
5. Reintroduce advance run only outside the critical section and validate cycle time versus path quality.

Confirm measured vs commanded pose after sync

Recalibrating the tool because $POS_ACT “looks double” can permanently damage a good TCP. Likewise, adding compensatory offsets in the PLC or in a submit interpreter without understanding advance run creates version-locked tribal fixes. Document which KSS version the cell runs—8.2 versus 8.3—when you capture traces for vendor support, and note whether absolute accuracy options or special bases are active.

Robot and PLC integration cells that exchange poses over fieldbus should define whether the shared frame is commanded or measured and stamp that definition in the interface specification. Aligning that contract early prevents false scrap events when a PLC & PAC systems sequencer triggers on a pose that the advance run has not yet truly reached.