Parametric Robot Control

🚀Getting Started

This section contains general information on the motion command structure of Parametric Robot Control. Specific topics are addressed in separate pages:

📁Installation 🎫Certificates 📜Licensing 🖥️Server Grasshopper Grasshopper 2 Blender - Geometry Nodes

In order to define robot programs, PRC utilizes the following categories of components:

Motion Groups#

Motion groups serve to structure motion commands and to reduce overhead (e.g. when the tool geometry is individually specified for each motion. A motion group defines the interpolation, tool, and base for all motions contained within. PRC supports the following motion groups:

  • Point-to-Point (PTP) Motion Group: This motion group may contain either Axis motion commands or Cartesian PTP commands.
  • Continuous Path (CP) Motion Group: This motion group may contain LINear and CIRcular motion commands
  • SPLINE Motion Group: This motion group may contain PTP and LINear motion commands, which are interpolated as a smooth spline through the waypoints. Note that the SPLINE group is not yet supported by the KSS KRL code generator. Independently of this group type, the KSS KRL driver can emit single-point spline commands (SPTP/SLIN/SCIRC) for regular PTP and CP motion groups via the UseSplineMotions setting.

Motions#

Motions define a robot motion. In general, a motion consists of a target (Cartesian or Joint) alongside values for the speed, interpolation, and acceleration. By default, CP speeds are given in m/sec, while PTP/Axis speeds are given as a factor of the maximum speed between 0.0 and 1.0 (e.g. 0.15 = 15%). These motion types are currently implemented:

  • LINear Motion: The target position is defined by a Cartesian Target.
  • PTP Motion: The target position is defined by a Cartesian Target and a posture. The posture is a status/turn configuration string (e.g. 110) that selects which of the possible axis configurations the robot uses to reach the Cartesian target.
  • Axis Motion: The target position is defined by a Joint Target.
  • CIRC Motion: Three target positions as Cartesian Targets define an arc.

Actions#

Actions define a robot action. The action types are currently implemented:

  • Hold: The robot waits for a timespan defined in seconds.
  • Insert Code: Inserts a given code into the program. The code is not simulated.
  • Set Variable: Sets a robot variable to a given value.
  • Wait for Variable: Waits for a robot variable to be set to a given value.
  • Ping: Pings the PRC server, e.g. to verify the connection from within a program.

Flows#

Flows allow you to define the data flow of a process. These flow types are currently implemented:

  • If-Else: Split the dataflow according to a variable that is checked at runtime.
  • While: Repeat an action while waiting for a variable to reach a given state.
  • End: End the execution of a program.

Task#

The commands above can be grouped within a Task. The task type defines how the server processes the task:

  • Simulate: Only simulate – no execution on the real robot.
  • Execute: Execute directly without simulation.
  • Execute on Simulation Success: Execute only if the simulation shows no errors.
  • Simulate and Execute: Simulate, then execute regardless of the simulation result.
  • Container: Groups sub-tasks without an own execution type.

Variables#

Variables carry a name and a typed value (bool, float, int, or string). They can be set from within a program via the Set Variable action, or externally at runtime via the gRPC UpdateVariable call. Variables are evaluated by the Wait for Variable action and by the If-Else and While flows – variable names such as $IN[1] are passed through to the robot controller by the driver. A client can also connect purely to exchange variables and monitor connected machines, without controlling a robot – see the Supervisor driver on Available Robots and Drivers.

Basics#

A robot program should ideally start with an axis motion (grouped within a PTP Motion Group) so that the start position is clearly defined. If a motion group does not reference a specific tool or base, either the previous or the default tool/base (as defined in the settings) is selected. The same applies to the programmed speed.

If a program starts with a Cartesian motion instead, the driver automatically injects a motion to the configured axis start position, followed by a forced-posture PTP using the Initial Posture driver setting (e.g. 110). Setting the Initial Posture to None skips only the forced-posture PTP – the program still starts with the motion to the configured axis start position, and the posture at the first Cartesian motion follows implicitly from it. The simulation then derives its posture from that start position via forward kinematics. Since no explicit status/turn is programmed, None can lead to differences between the simulation and the real robot, especially near singular start positions.

The commands are processed in order. For example: A task contains a PTP Motion Group "Start", followed by a While block that references the variable $IN[1] and the PTP Motion Group "Loop". The While block is followed by the PTP Motion Group "End".

  • Task "Program"
  • PTP Motion Group "Start"
  • While
  • PTP Motion Group "Loop"
  • PTP Motion Group "End"

That program would start with "Start" and then repeat "Loop" until $IN[1] is TRUE, then it will process "End" and terminate the program.

Last updated 2026-07-29