Configuring KUKA Sim 3.1 Speed for PTP and Linear Moves

The robot runs at the wrong speed in KUKA Sim 3.1, and the speed appears editable only while teaching a point. Treat the motion-statement setting, Python servo control, and generated KRL as three separate control paths. First decide whether the required speed belongs to an existing simulated program move, a Python-driven simulation, or the program exported for the controller.

Speed-control path selection

1. Select an existing motion statement. Click the required PTP or linear statement in the Programming tab. If its properties expose the intended speed setting, edit that value and confirm that the statement retains it after selection changes. Continue with statement-level configuration.
2. Identify Python-driven motion. If a Python script directly commands a servo or its joints, the statement editor is not the active control path. Continue with servo scripting and obtain the valid property names from the installed scripting interface.
3. Identify exported controller code. If the required result is a KRL program containing BAS(#VEL_CP,2.0) or BAS(#VEL_PTP,100), configure the simulated motion first, then use a post processor that maps the simulation data into KRL. Python syntax does not replace those KRL instructions directly.

Before anything else, confirm which artifact must change: the selected statement, the live simulation behavior, or the exported KRL file. A speed change in one path does not automatically prove that either of the other two changed.

Existing PTP and linear statements

Creating or reteaching a point is unnecessary when only the move speed must change. The point defines a destination; the motion statement defines how the robot travels to that destination. Select the existing statement and edit its speed through the Programming tab.

1. Open the robot program in the Programming tab.
2. Select the exact PTP or linear statement whose execution speed must change.
3. Edit the statement's available speed value without creating a replacement point.
4. Save or apply the edited statement, then reselect it and confirm that the new value remains displayed.
5. Run only the affected portion where practical. Do not move on until the robot completes the same geometric move with a measurably different execution time.

KRL command interpretation

The commands BAS(#VEL_CP,2.0) and BAS(#VEL_PTP,100) are KRL, not Python. They express two different speed concepts and must remain associated with the appropriate motion type.

The values 2.0 and 100 are not interchangeable simply because both affect speed. Continuous-path and PTP motion use different speed representations. Read the units or scaling shown by the motion editor and the target KRL environment before transferring a value between them.

If manual KRL edits work in KUKA Sim 4.0 but the same editing route is absent in KUKA Sim 3.1, use the interfaces actually exposed by version 3.1: statement properties for programmed moves or Python servo control for scripted simulation. Use post-processing for the KRL deliverable.

Python servo-control branch

Use Python only when the simulation must drive the robot through component scripting rather than execute an ordinary PTP or linear program statement. The relevant mechanism is servo and joint control. A script supplies motion commands to the simulated servo; it does not become KRL merely because the simulated robot moves correctly.

1. Open the component-scripting environment associated with the robot or servo behavior.
2. Identify the servo or joint interface used by the installed KUKA Sim 3.1 component.
3. Read the exposed speed-related property or command from that interface. Property names are component- and interface-specific, so use the names displayed by the installed scripting API rather than inventing a Python equivalent of #VEL_CP or #VEL_PTP.
4. Command a deliberately distinct test speed within the model's configured limits.
5. Run a short, repeatable move and record its start-to-finish simulation time.
6. Change only the scripted speed input and repeat the same move. Do not move on until the elapsed time changes while the destination remains unchanged.

If the statement editor still controls the move, adding a servo script creates competing control paths. Stop the program-statement execution during the servo test, or disable the script while validating statement-level speed.

Post-processor translation

A post processor bridges the simulation program and controller-language output. It reads motion and speed information represented in the simulation and emits target KRL. This is the resolving branch when the simulation must produce commands such as BAS(#VEL_CP,2.0) and BAS(#VEL_PTP,100).

1. Set the speed on each required PTP or linear statement, or establish the speed data used by the scripted workflow.
2. Select a post processor that produces KRL for the target robot program.
3. Generate the output into a reviewable file.
4. Inspect each affected motion block. Confirm that the continuous-path setting precedes the intended linear motion and that the PTP setting precedes the intended PTP motion.
5. If the KRL lacks the speed command, inspect the post processor's mapping of simulation speed data. Changing Python execution alone does not require the exporter to emit a corresponding KRL instruction.
6. Regenerate after correcting the mapping; do not rely on a one-off manual edit if the file will be exported again.

Resolving-branch verification

1. Record the original elapsed time for one repeatable PTP move and one repeatable linear move.
2. Change each speed through its chosen control path while leaving the destinations unchanged.
3. Replay both moves and confirm that each elapsed time changes in the expected direction.
4. Generate KRL and inspect the placement of BAS(#VEL_PTP,100) and BAS(#VEL_CP,2.0) where those exact configured values are required.
5. Generate the program a second time and verify that the same speed commands and motion associations remain present.

Frequently asked questions