← Zinan Yang · lab
Unofficial notes · Siemens application library · Entry ID 109755891 · LKinCtrl V5.3 · 04/2026

Kinematics Control
LKinCtrl V5.3

LKinCtrl turns a TO Kinematics into something you drive with a list. Instead of chaining single motion jobs in your user program, one function block — LKinCtrl_MC_MovePath — reads a PathData command list and executes it as one continuous, blendable path that can be stopped, interrupted and continued from its inputs, with detailed execution status and diagnostics on the way out.

S7‑1500T · TO Kinematics Linear · circular · sPTP · conveyor tracking Flags · frames · zones · tools Standalone power, reset, home, jog, pick&place

Personal study notes — not a Siemens publication. The manuals on Siemens Industry Online Support are authoritative.

Introduction · Chapter 1

One command list, one function block

LKinCtrl gives the TO Kinematics technology object a command-list driven way to run path motions, plus HMI screens — documented separately — to commission and diagnose the kinematics and its axes. This is why the library exists, and what it is built from.

Instead of executing and handling several single motion commands in the user program, the TO Kinematics is controlled by only one core function block. Path information is provided by a list of commands, not by program logic. Path motions can be stopped, interrupted and continued during execution just by inputs on that one block. Detailed information on the path execution status, together with error diagnostics, comes back out of the same block.

Before and after

A conventional program wires up one motion block per step and handles each one's own done / busy / error logic in turn. LKinCtrl collapses that into a single instance of LKinCtrl_MC_MovePath reading a PathData command list.

Without LKinCtrl
User program logic MC_MoveLinear MC_MoveCircular MC_MoveDirectAbsolute MC_MoveLinear done / busy / error handled per command

Four commands, four sets of interface handling — and the sequencing itself lives in the user program.

With LKinCtrl
PathData 1 MoveLinear 2 MoveCircular 3 MoveDirectAbs. 4 MoveLinear LKinCtrl_MC_ MovePath FB 35000 TO Kinematics status · diagnostics readyForNextPath

One instance keeps reading the list, keeps the MotionQueue full, and reports progress and errors back through a single interface.

Architecture and concept

The path motion is defined by parametrizing a command list, called PathData. Its parametrization follows the parametrization of the underlying system functions and includes the available system motion commands for TO Kinematics; the PathData length can be adapted to the use case through an internal library user constant.

PathData serves as an IN_OUT parameter for the application's core FB LKinCtrl_MC_MovePath. This function block controls the TO Kinematics and internally executes the motion commands as defined in the PathData. It can interrupt, continue and stop the path motion, and offers detailed diagnostics information in its interface. It also manages to steadily keep the TO's job sequence full without overloading it, so that a maximum look-ahead in terms of dynamic planning is achieved.

Benefits

Comfortable path definition in a command list
Execution of motion commands according to the command list
Single step / automatic mode for path execution
Diagnostic interface
Flags for actuator control depending on path status
Flags for sequence control (wait conditions)
Wait times in command sequence
Activation / deactivation of single path commands
Compensation of tool and radius length
Complete set of configuration functions programmable in the command list
Auxiliary functions to enable / home / reset all axes of the axes group
Familiar interface behaviour of motion commands
Memory and runtime optimised function blocks
Comfortable point definition in a point table
Encapsulated command sequence for pick and place applications, with integrated conveyor tracking
Measurement command functionality to abort a single command within a path

Components used

Alongside the core FB, the library ships two further motion blocks that share its interface conventions: MC_JogFrame provides jogging of a kinematics in Cartesian directions X, Y, Z including the orientation axis — continuously, incrementally, or to a specified target position — and LKinCtrl_MC_MovePickAndPlaceLinear encapsulates a linear MC command sequence for typical pick-and-place applications, usable like a standard MC block, with conveyor tracking integrated so no additional command is needed to establish tracking.

Hardware used to build this application example
ComponentNo.Article numberNote
CPU 1518T‑2 PN16ES7 518‑4UP00‑0AB0Or other S7‑1500T CPU with FW 3.1.0

Available from the Siemens Industry Mall.

Files that make up the application example
LKinCtrl libraryLKinCtrl_V5_3_1_TiaLib_V19.zip
LKinCtrl manualLKinCtrl_V5_3_1_Manual_en.pdf
LKinCtrl manual HMILKinCtrl_V5_3_1_Manual_HMI_en.pdf
Getting started projectLKinCtrl_V5_3_1_GettingStarted_TiaPrj_V19.zip
Getting started manualLKinCtrl_V5_3_1_GettingStarted_Manual_en.pdf
ChangelogLKinCtrl_V5_3_1_Changelog_en.pdf
NOTE The application can run on all 1500T CPU types with firmware V3.1.0 or greater and motion control V8.0 or greater. The Unified HMI requires firmware V19.0.0.2 or greater.
Engineering · Chapter 2, 5 · FB 35000

LKinCtrl_MC_MovePath

The block engineers actually call. It reads the PathData command list, drives the TO Kinematics, and is the one instance you wire into the cyclic task — everything else in the library supports it.

Project integration

Requirements

To run the application, a basic TIA Portal V19 project with a TO Kinematics and the corresponding number of TO PositioningAxis objects needs to be set up. The TO Kinematics must be configured, and a basic commissioning to run the kinematics with the control panel should be completed — this can also be done with the commissioning module in the HMI.

Import of the application

Integrating the library blocks into a STEP 7 program follows a fixed sequence of drag-and-drop copies:

No.Action
1Copy the folder LKinCtrl_Tags with drag & drop into "PLC tags" in the PLC.
2Copy the folder LKinCtrl_Types with drag & drop into "PLC data types" in the PLC.
3Copy the folder LKinCtrl_Blocks with drag & drop into "Program blocks" in the PLC.
4(Optional) Copy the folder LKinCtrl_Data with drag & drop into "Program blocks" in the PLC. Existing data, or separately created data, can also be used for the interface of the library blocks.
5The blocks can now be configured and called in the user program.
NOTE Follow the sequence of inserting the folders.

Block interface

The interfaces and controls of the LKinCtrl blocks follow the PLCopen standard; they are implemented in SCL for use in a cyclic task. The table below is the full parameter list of LKinCtrl_MC_MovePath — filter it by parameter type, or scan the whole thing.

NOTICE Due to the block's internal structure, only optimized DBs can be used for its interface data. Using non-optimized DBs sends the CPU to STOP mode.
Show: All parameters IN OUT IN_OUT
NameTypeData typeComment
Inputs
executeINBoolRising edge starts action once.
stopINBoolAbort path motion.
interruptINBoolInterrupt path motion.
resetINBoolReset FB / acknowledge errors.
sequenceModeINIntActivate sequence mode (0) / single step mode (1).
pathTransitionINDIntInitial transition configuration for a new path motion (1: use bufferMode and transitionParameter).
bufferModeINDIntInitial buffer mode for a new path motion.
transitionParameterINArray[1..5] of LRealInitial transition parameter for a new path motion.
configurationIN"LKinCtrl_typeConfiguration"Configuration structure — see below.
abortMeasurementCmdINBoolTRUE: abort the active command if it is a measurement command.
Outputs
doneOUTBoolTRUE: commanded functionality has completed successfully.
busyOUTBoolTRUE: FB is not finished — new output values can be expected.
activeOUTBoolFB is in control of the axesGroup / kinematic is in motion.
commandAbortedOUTBoolTRUE: commanded functionality was aborted by another command.
errorOUTBoolTRUE: an error occurred during execution of the FB.
statusOUTWordStatus of the FB (constants in the status & error reference).
diagnosticsOUT"LKinCtrl_typeMovePathDiagnostics"Diagnostics information of the FB.
activePathDataOUTString["LKINCTRL_LENGTH_OF_PATHDATA_NAME"]Name of the actual PathData.
activeCmdNoOUTDIntNumber of the actual PathData command.
remainingDistanceActCmdOUTLRealRemaining distance of the actual PathData command.
readyForNextPathOUTBoolTRUE: the next PathData can be triggered.
activeUserFramesOUTArray["LKINCTRL_CS_NO_OF_FIRST_USER_FRAME".."LKINCTRL_CS_NO_OF_LAST_USER_FRAME"] of "LKinCtrl_typeFrame"Currently active user frames.
bufferedCommandsOUT"LKinCtrl_typeBufferInfo"Current buffered commands, including history.
In/out
axesGroupIN_OUTTO_KinematicsReference to the axesGroup.
pathDataIN_OUTVariantReference to the PathData.
pointTableIN_OUTArray[*] of "LKinCtrl_typePoint"Reference to the point table.
flagsIN_OUTArray[0.."LKINCTRL_NO_OF_LAST_SETFLAG"] of BoolBoolean defined by setFlags in a PathCommand.
valueFlagsIN_OUTArray[0.."LKINCTRL_NO_OF_LAST_VALUEFLAG"] of LRealValue defined by valueFlags in a PathCommand.
NOTE The axesGroup, pathData, pointTable and flags in/outs must be connected to their corresponding objects — they are not optional.
NOTE Resetting the function block, or acknowledging its errors, is only possible when busy = FALSE.

Configuration structure

The configuration input carries settings that apply across the block's operation — offset and conveyor parameters, user and zone frames, and the stop/interrupt dynamics:

FieldTypeComment
offsetParameterArray[1.."LKINCTRL_NO_OF_OFFSETS"] of "LKinCtrl_typeContourOffsetParameter"Offset parameter settings for contour offset commands.
conveyorParameterArray[1.."LKINCTRL_NO_OF_CONVEYOR"] of "LKinCtrl_typeConveyorConfiguration"Conveyor parameter settings for conveyor tracking commands.
userFramesArray[first..last user frame] of "LKinCtrl_typeFrame"User frame configuration — additional frames beyond OCS1–3, used as coordinate system 11…n at the command.
workspaceFramesArray[1.."LKINCTRL_NO_OF_ZONES"] of "LKinCtrl_typeWorkspaceZoneDefinition"Workspace zone configurations used for zone commands.
kinematicsFrameArray[1.."LKINCTRL_NO_OF_ZONES"] of "LKinCtrl_typeKinematicsZoneDefinition"Kinematics zone configuration used for zone commands.
stopModeDIntMC_GroupStop dynamics: 0 stop with dynamics of the active job; 1 stop with maximum kinematics dynamics (adaption still effective); 10 / 11 as 0 / 1 plus desync conveyor.
interruptModeDIntMC_GroupInterrupt dynamics: 0 dynamics of the active job; 1 maximum kinematics dynamics (adaption still effective).
errorStopModeDIntMC_GroupStop dynamics when stopping due to an error — same value set as stopMode.
preloadMotionQueueUSIntPreload the motion queue via interrupt/continue before the start of motion: 0 no preloading; 1 preload and start when prepared; 2 preload and start with acknowledge (rising edge at execute).
resetModalDynamicsBoolTRUE: internal modal dynamics are reset between paths. FALSE: kept between paths.

Calling the block

Once a PathData structure has been created in a DB, the FB is called cyclically. The axesGroup, pathData, pointTable and flags in/outs must be connected to their corresponding objects; the execute signal that starts the path motion can be wired to an input pin, or set in the code of an SCL block.

CAUTION Only trigger one instance at a time. Triggering multiple instances of the function block against the same TO Kinematics at the same time makes both instances try to execute commands, mixing up the order of the MotionQueue and potentially causing unexpected kinematics motion. This is never necessary — one instance can handle multiple PathData structures, one after another, in an optimised period of time.

Operation

General functionalities

Based on PLCopen Part 4 behaviour, execute reacts to a rising edge. The other control inputs each map to a distinct system-level action:

Start / continue

A rising edge at execute starts a new path motion, or — after an interrupt — continues the interrupted one.

Stop

stop triggers MC_GroupStop internally: the path motion is aborted and every executed command is deleted from the MotionQueue.

Interrupt

interrupt triggers MC_GroupInterrupt: motion status and all executed commands stay in the MotionQueue, and can be continued.

Reset

reset acknowledges errors or performs a general reset of the FB, once busy = FALSE.

Mode selection

sequenceMode switches between automatic and single step operation — see Operating modes.

Actuator control

Actuators can be controlled via flags depending on path motion status, alongside the stop-mode and offset settings in configuration.

Diagnostics & status

Diagnostic output splits into two groups. The PLCopen-style outputs — done, busy, active, commandAborted, error and status — follow the timing behaviour of the PLCopen-conformant system motion commands. Beyond that, the diagnostics structure is written whenever an error occurs: it identifies the command number and PathData name that may have caused it, the state-machine states of LKinCtrl_MC_MovePath and LKinCtrl_ExecuteKinMotionCmd, and the TO Kinematics' own status and error words.

While a path motion runs, activePathData and activeCmdNo report which command is executing and in which PathData, and remainingDistanceActCmd reports the remaining distance of that single command. readyForNextPath switches TRUE once every command in the current PathData has been internally executed into the MotionQueue — not that those commands have finished, only that they are queued — and that is the signal to trigger the FB again with the next PathData, keeping the MotionQueue filled for maximum look-ahead.

Operating modes

sequenceMode switches the FB between two distinct ways of working through a PathData. The difference is how much of the list one execute edge commits to:

Automatic mode · sequenceMode = 0 Single step mode · sequenceMode = 1
Automatic (0, default)Single step (1)
Per execute edgeRuns the complete PathDataRuns exactly one command
done signalsAfter the last command in the PathData finishesAfter each single command finishes
RetriggeringPossible on done = TRUE, or as soon as readyForNextPath goes TRUE — keeps the MotionQueue filledA new rising edge on execute is required for every command
Blending between commandsConfigured via the next command's first entry, or overridden at the FB via pathTransition / bufferMode / transitionParameterNone — bufferMode is ignored, see caution below
Best suited toProduction operation, continuous pathsCommissioning, step-through diagnosis

Once readyForNextPath signals that a PathData's commands are all registered in the MotionQueue, the FB can be retriggered with the following PathData — the queue stays filled and the path continues immediately once the first PathData ends.

Transitions between two path motions can be configured either in the following PathData's first command entry, or by setting pathTransition = 1, which overwrites that entry's blending parameters with the ones set at the FB inputs bufferMode and transitionParameter[1..5].

NOTE pathTransition = 1 enables the blending parameters bufferMode and transitionParameter[1..5] for the transition between two PathData structures.

Behaviour worth knowing before you call it

Triggering multiple commands per call

The FB can trigger more than one command per call, which helps keep the MotionQueue filled and can improve path dynamics. This is enabled by raising the PLC tags LKINCTRL_NO_OF_START_EXECUTE_CMDS and LKINCTRL_NO_OF_SEQ_EXECUTE_CMDS in the tag table LKinCtrl_Configuration.

NOTE Increasing the number of commands triggered per call can increase cycle time. To save cycle time, the repetition is not always carried out in full — for example, if the MotionQueue is already full, the loop exits early.

Continue at start

An undesired TO Kinematics behaviour can leave blending between two commands incorrect after an interrupted command is aborted with no continue following it. Because an interrupt always needs a matching continue, LKinCtrl_MC_MovePath executes a continue command before starting the path motion, to guarantee one always follows. This behaviour is controlled by the internal constant CONTINUE_AT_START.

Interactive · §3 Programming & supported commands

Path lab

A PathData structure is just an array of commands — LKinCtrl_typePathDataElement entries read in order by LKinCtrl_MC_MovePath. Build one below in the manual's own command types, then watch it execute exactly as the block reports it: which entry is active, how fast the path is moving, and whether it is running, interrupted or stopped.

PathData · commands
cmdType −1 · End of path — no commands run after this entry
Idle Executing: — Path velocity: 0 mm/s
Browser model This lab is a browser model of LKinCtrl's documented behaviour, built from the V5.3 manual. Geometry, blending and timing are illustrative — not the real TO Kinematics interpolator.
LKinCtrl_MC_MovePath · inputs
sequenceMode
Speed× 100%
Viewer-only playback scaling of the simulated path velocity — not an FB input. Real velocity is set with the commands 70–72 (§3.6).
Outputs
flags[0..6]
Set by setFlags in the active command; click a lit flag to acknowledge a wait–point (flag modes 5, 25, 26).
Linear / circular (blended) MoveDirect / sPTP Circle centre Auxiliary point Programmed corner (cut by blending) Flag switches here Wait‑time dwell Current tool position
Getting started · Entry ID 109755891 · LKinCtrl V5.3 · 04/2026

The getting‑started demo, opened up

Siemens ships LKinCtrl with a ready‑to‑run TIA Portal project: a simulated 4‑axis kinematics running three scenarios — a traced contour, a pick&place packaging cell and a conveyor‑tracking hand–off — driven by a Unified HMI. Everything below is read out of that project's own exported source, not paraphrased from the manual: real block names, real tag names, and the actual PathData the demo executes.

The project consists of four TO PositioningAxis configured as virtual (simulated) axes, connected to a TO Kinematics defined as a 3D Rollpicker with orientation. Two further virtual TO PositioningAxis represent the conveyor belts used for conveyor tracking. On the PLC side the example contains two call environments — one that drives the kinematics, one that feeds the Unified HMI — plus one FB per scenario that runs its automatic sequencing. Since the HMI is optional, every scenario can equally be driven from a Watch table.

Components used §1.2

ComponentQtyArticle no.Note
CPU 1518T‑2 PN16ES7 518‑4UP00‑0AB0Or other S7‑1500T CPU, FW ≥ 3.1.0
MTP2200 Unified Comfort PRO16AV2 128‑3XB27‑0BX0Or other WinCC Unified panel, FW V19.0.0.2

The project file inspected for this page (…TiaPrj_V19_V21) is the same demo re‑saved in TIA Portal V21 Update 2 HF1; the manual's own steps below assume TIA V19 or higher.

Kinematics traceThe kinematics trace is already configured to start recording on every execute of LKinCtrl_MC_MovePath, and it traces OCS1–3 as well — so a scenario's actual path can be checked against its predefined contour without adding anything.
Scenario 1A / 1B · ContourPath 1 / 2

Traces the outline of an “S” and its circumscribing circle — a stand‑in for glue, print or cutting work where the TCP must follow a predefined contour precisely. 1A runs in the world coordinate system; 1B runs the identical shape inside OCS3, so redefining that frame simply relocates the whole contour.

Scenario 2 · PackagingPath 3

A product arrives on a (simulated) conveyor, is picked, rotated 90° and placed into one of four slots in a box; the place point is re‑derived from a UCS each cycle so the same path serves all four slots. Path data is written directly in SCL, not via the HMI.

Scenario 3 · Pick&place trackingPath 4

A product on conveyor 1 is picked on the fly, carried to conveyor 2 and placed there while both belts keep moving — the TCP tracks OCS1 then OCS2. Path data is also written directly in SCL. Stopping mid‑tracking raises a TO error by design and must be acknowledged.

Flags & points these scenarios share §2.1–2.2

All three scenarios read and write the same setFlagNames / pointTable arrays in ExampleProject_Data — these are the indices Scenario 1 and 2 name.

KindIndexNameComment
SetFlag0S1 Enable actuatorrising edge: enable actuator
SetFlag1S1 Disable actuatorrising edge: disable actuator
SetFlag2S2 Pick readyTRUE: product ready to be picked
SetFlag3S2 Open actuatorrising edge: open actuator
SetFlag4S2 Close actuatorrising edge: close actuator
Point1S2 Above placeposition above the place location
Point2S2 Placeposition to place the product

Watch the Scenario 1 actuator live at "InstExampleProject_S1_Contour".actuator, Scenario 2's at "InstExampleProject_S2_Packaging".actuator, and the place cycle at "InstExampleProject_S2_Packaging".placeIndex; Scenario 3's conveyor speeds and product interval are set at "ExampleProject_Control".scenario3VelocityConveyor1/2 and .scenario3ProductIntervalConveyor1.

Commissioning the example §3

In the manual's own order: prepare and download once, then drive it from either a Watch table or the Unified HMI.

1Prepare and download
  • Open the example project in TIA Portal V19 or higher.
  • Optional — if PLCSIM or PLCSIM Advanced is used, skip this. On a real PLC: right‑click it → Change device, select the real PLC and firmware, confirm.
  • Right‑click the PLC → Download to device — download hardware and software, then start the PLC.
2Operate via Watch table
  1. Right‑click the PLC → Go online; open Watch table “Start scenario”.
  2. Enable monitoring on the Watch table.
  3. Set "ExampleProject_Control".masterControlWatchTable to TRUE — while FALSE, Watch table signals are ignored or overwritten.
  4. Set .resetAxes, .enableAxes and .homeAxes to TRUE. Reset and home act on a rising edge.
  5. Choose a scenario via .watchTableScenario: 1 Scenario 1A · 2 Scenario 1B · 3 Scenario 2 · 4 Scenario 3.
  6. Confirm all axes are enabled and homed, with no error on axes or move path.
  7. Set .pathOverride to the desired velocity override, then set .executeScenario to TRUE.

Driven this way, a scenario retriggers indefinitely as soon as the move path is ready again — stop it with a rising edge on .stopMovePath (also: .interruptMovePath, .resetMovePath). This is Full operation mode: no HMI restrictions apply.

3Operate via the Unified HMI
  • Optional — skip if using a Unified Runtime simulation. On a real panel: right‑click the HMI → Change device / version, select it, confirm.
  • Start the Unified HMI simulation, or download to the real HMI. A simulated runtime opens in a browser at https://localhost (or the computer's name in place of localhost).
  • The library's screens sit inside a title bar, sub navigation and status bar that the example project adds around it. The sub navigation's screen list is a JSON string on the faceplate in screen 01_Layout:
    {"default": [
      {"screen": "LKinCtrl_Editor_Layout", "textListIndex": 1},
      {"screen": "LKinCtrl_Commissioning_Layout", "textListIndex": 2},
      {"screen": "LKinCtrl_Diagnostics_Layout", "textListIndex": 3}
    ]}
    the same mechanism configures the main navigation in screen 03_MainNavigation.
  • In the status bar, pick an operation mode:
    ModeEditingProgram exec.Teaching
    No operationlockedlockedlocked
    Automaticpossiblepossiblelocked
    Manualpossiblelockedpossible (manual vel.)
    Test runpossiblepossiblepossible (test‑run vel.)
    Full operationNo HMI in use — no restrictions; used automatically when driven from the Watch table
  • Start a scenario: select Automatic or Test run → pick the scenario → reset, enable and home the axes → press play. The play control only enables once the mode is right and every axis is homed, enabled and fault‑free.

The status bar's kinematics controls, from the manual's own table:

ControlAction
Homehomes all connected kinematic & conveyor axes; LED green once every axis is homed
Enabletoggles enable for all connected axes; LED green once every axis is enabled
Resetresets the kinematics and all connected axes; LED red on any fault (axes, conveyors or move path)
Start / continuestarts, or resumes an interrupted, path motion execution
Interruptinterrupts the path motion execution
Abortaborts the path motion execution
Note §3.2.2In Automatic the scenario repeats until stopped by hand; in Test run it executes once. Path motion can only start in Automatic or Test run, and only once every connected axis is homed, enabled and fault‑free — and status‑bar input is ignored entirely while the Watch table's master control is enabled.
Note §2.3Stopping Scenario 3 while it is tracking a conveyor raises a technology‑object error by system design — it must be acknowledged before the next run, or stop it cleanly by switching to Test run and letting the current cycle finish.

The status bar's user icon opens a login dialog. The project ships predefined user roles that aren't evaluated by default; enabling user administration on the Settings page then locks the HMI until Administrator / Administrator logs in.

What's actually inside the project

Read straight out of the TIA Openness/VCI export under Vci/ — real object names, and the folder each lives in so you can find it again in TIA Portal.

Kinematics & axes Technology objects

  • Rollpicker — TO_Kinematics, “3D Rollpicker with orientation”Vci/PLC/Technology objects/ExampleProject_TOs/Rollpicker.xml
  • Rollpicker_A1 … Rollpicker_A4 — 4× TO_PositioningAxis, virtual kinematic axes…/ExampleProject_TOs/Rollpicker_A1 … A4/
  • ConveyorAxis_1, ConveyorAxis_2 — 2× TO_PositioningAxis, virtual conveyor axes (Scenario 3)…/ExampleProject_TOs/ConveyorAxis_1, _2/

The project also ships a GSDML for a SINAMICS S210 servo drive (AdditionalFiles/GSD/), even though every axis above is configured virtual — the six drive channels aren't exercised by this demo.

Program blocks ExampleProject_Blocks

  • ExampleProject_Main — OB123, Program Cycle. Calls Call_Env, Call_Env_HMI and the three scenario FBs.
  • ExampleProject_Startup — Startup OB. Initialises flag/point names and writes Scenario 2 & 3's PathData into retain memory.
  • Call_Env, Call_Env_HMI — the two call‑environment FCs (kinematics control; Unified HMI feed).
  • ExampleProject_S1_Contour, _S2_Packaging, _S3_PickAndPlaceTracking — the three scenario FBs (called as InstExampleProject_S1… etc.). Their own body isn't included in this export — only their calls and interface are visible.
  • ExampleProject_Data — the recipe DB: pathDataArray, pointTable, flag names, settings. Retentive.
  • ExampleProject_Control / _Status — the Watch table / command & status interface (see step 2 above).
  • Statusbar_HMI — the project's own status‑bar FB; not part of the library.

LKinCtrl library blocks present LKinCtrl_Blocks

  • LKinCtrl_MC_MovePath, _MC_JogFrame, _MC_MovePickAndPlaceLinear, _PathDataConversion — top‑level motion FBs.
  • LKinCtrl_AuxBlocks_MC_GroupPower, _MC_GroupReset, _MC_GroupHome plus the status/warning/error‑word helpers.
  • LKinCtrl_SubBlocks — the execution engine: _MC_ExecuteKinMotionCmd and _PreBuffer directly, plus _ContOffsetBlocks (1 file), _MovePickAndPlaceBlocks (19 files — pick&place geometry) and _SubCalcBlocks (37 files — frame transforms, blending distance, flag control and the rest of the path maths).
  • LKinCtrl_HMI_Blocks — the faceplate logic behind the Unified HMI: Commissioning (Configuration, Control Panel), Diagnostics, Editor (Path Editor, Point Editor), Shared (Pickers, Teach Kinematics, Utilities) and the Teach Kinematics blocks.
  • Matching PLC data types under LKinCtrl_Types / LKinCtrl_HMI_Types, and tag tables LKinCtrl_Configuration, LKinCtrl_Constants, MC_Constants.

HMI Unified Comfort

  • Device HMI_RT_2, type MTP2200 Unified Comfort PRO, RT firmware 19.0.0.2 — matching the manual's stated hardware.
  • Screens export as numbered runtime files (IM/HMI/I/0/Saved/screens/screen_<id>.rdf) rather than by name, so screen names above (01_Layout, 03_MainNavigation, the module screens) are taken from the manual, not decoded from this export.
  • Instances called from Call_Env_HMI: InstStatusbar_HMI, InstLKinCtrl_Editor_HMI, InstLKinCtrl_Commissioning_HMI, InstLKinCtrl_Diagnostics_HMI, InstLKinCtrl_TeachKinematics_HMI.
Not in this exportThe Vci/Openness export is PLC software plus a WinCC Unified content export — it carries no device/network (hardware) configuration, so the actually‑configured CPU model can't be independently confirmed here; the hardware table above is the manual's own. The three scenario FBs' bodies are likewise outside this export — only their calls, instance names and interfaces are visible.

The example's own PathData

Scenario 1's contour was authored on the HMI and ships as retained start values inside "ExampleProject_Data".pathDataArray — decoded below from that DB's exported start values. Scenarios 2 and 3 are written directly in SCL, in ExampleProject_Startup, precisely to show a use case with no HMI involved.

10 active commands, pathDataArray[1], all in WCS. Positions in mm (the TO's configured engineering unit); path velocity likewise per second. The circular moves give their aux point as an offset from the previous target and a travel arc in degrees rather than a radius — that's circMode = 1 (centre + arc) on all three of them here. The DB provisions five path slots in total; only four are used by these scenarios — the fifth, named “Path 5”, ships empty.

#NameCommandTargetBufferVelNotes
1B_upMoveLinAbsx0 y28.28 z50 a0BlendingLow300SetFlag 1 (disable actuator) before move
2BMoveLinAbsx0 y28.28 z0 a0BlendingLow300
3CircMoveCircAbsarc 360°Buffered150SetFlag 0 (enable actuator) before — the circumference circle
4D_upMoveLinAbsx10 y10 z50 a0Buffered300
5DMoveLinAbsx10 y10 z0 a0BlendingLow300
6WaitTime3000 msBufferedcmdActivated = FALSE — disabled by default; flip it TRUE (Watch table or HMI) to pause 3 s after cmd 5
7S_upMoveCircAbsaux Δy10, arc 235°Buffered150SetFlag 0 (enable actuator) before
8FMoveLinAbsx5.74 y−1.81 z0 a0BlendingLow300
9S_loMoveCircAbsaux Δy−10, arc 235°BlendingLow150SetFlag 1 (disable actuator) after
10MoveLinRelΔz +50Buffered−1 (TO default)retract, closing the loop back to the start height

Scenario 1B (pathDataArray[2], “contourOCS”) repeats this exact shape, prefixed with one extra command — SetOcsFrame assigning OCS3 an origin of x100 y0 z0 — and every subsequent command's coordinate system switched from WCS to OCS3. Move the frame, and the whole “S” moves with it.

How the example calls the library

Two call chains hang off ExampleProject_Main (OB123): one drives the kinematics, one feeds the Unified HMI.

OB123ExampleProject_MainProgram Cycle
FCCall_Envkinematics control
  • InstLKinCtrl_MC_GroupPower
  • InstLKinCtrl_MC_GroupReset
  • InstLKinCtrl_MC_GroupHome
  • InstLKinCtrl_MC_MovePath
FCCall_Env_HMIUnified HMI feed
  • InstStatusbar_HMI
  • InstLKinCtrl_Editor_HMI
  • InstLKinCtrl_Commissioning_HMI
  • InstLKinCtrl_Diagnostics_HMI
  • InstLKinCtrl_TeachKinematics_HMI
also called directly from Main: InstExampleProject_S1_Contour InstExampleProject_S2_Packaging InstExampleProject_S3_PickAndPlaceTracking

Two real FBD call signatures, read straight from the exported networks. ExampleProject_Main wires the Rollpicker TO_Kinematics and the whole ExampleProject_Data record into Call_Env's InOuts; Call_Env passes the same objects straight on into InstLKinCtrl_MC_MovePath:

Call_Env FC

INexecuteMovePath, stopMovePath, interruptMovePath, resetMovePath, abortMeasurementCmd, groupPower, groupReset, groupHome, selectedPath
OUTmovePathTracking, movePathReadyForNextPath, movePathDone, movePathAborted, movePathError
INOUThomeMode, kinematics (TO_Kinematics), settings, pathData[*], pointTable, setFlags, valueFlags

LKinCtrl_MC_MovePath FB

INexecute, stop, interrupt, reset, sequenceMode, pathTransition, bufferMode, transitionParameter, configuration, abortMeasurementCmd
OUTdone, busy, active, commandAborted, error, status, diagnostics, activePathData, activeCmdNo, remainingDistanceActCmd, readyForNextPath, activeUserFrames, bufferedCommands
INOUTaxesGroup (TO_Kinematics), pathData, pointTable, flags, valueFlags

Only selectedPath and settings travel in from the Watch table / HMI side of Call_Env to choose & configure the path; sequenceMode, pathTransition, bufferMode, transitionParameter and configuration on the inner MC_MovePath call are set inside Call_Env itself, not exposed further out.

Standalone blocks the project uses

BlockWhere it runsHow it's invoked here
LKinCtrl_MC_GroupPowerInstLKinCtrl_MC_GroupPowerCalled directly by Call_Env; input enable driven from .enableAxes / the HMI's power control.
LKinCtrl_MC_GroupResetInstLKinCtrl_MC_GroupResetCalled directly by Call_Env; execute driven from .resetAxes (rising edge).
LKinCtrl_MC_GroupHomeInstLKinCtrl_MC_GroupHomeCalled directly by Call_Env; execute driven from .homeAxes (rising edge).
LKinCtrl_MC_JogFrameinstJogFrameInstantiated inside the library's own LKinCtrl_TeachKinematics block (called via InstLKinCtrl_TeachKinematics_HMI / _Commissioning_HMI) for manual jog moves in Teach mode and Commissioning — the example project never calls it directly. Region JOG_FRAME triggers it from whichever HMI faceplate or external jog input is active: jogForward, jogBackward, jogToPosition and jogSPTP each combine an HMI and an “external” source with a validity check.
LKinCtrl_MC_MovePickAndPlaceLinearinstMC_MovePickAndPlaceLinear[1..2]A 2‑element multi‑instance array inside LKinCtrl_MC_ExecuteKinMotionCmdMC_MovePath's own engine dispatches into it whenever a PathData command has cmdType = 11. This is exactly what Scenario 3's three motion commands run as.

The dispatch itself, quoted from LKinCtrl_MC_ExecuteKinMotionCmd:

// Reset instance
#instMC_MovePickAndPlaceLinear[#statFBCounterMoveLinPnP](axesGroup := #to_Kinematics,
                                                         execute   := FALSE);
IF #instMC_MovePickAndPlaceLinear[#statFBCounterMoveLinPnP].busy = FALSE THEN
  ...
  // Trigger command
  #instMC_MovePickAndPlaceLinear[#statFBCounterMoveLinPnP](execute     := TRUE,
                                                           position    := #pathDataElementPreBuf.cmdCoordinates.targetPosition,
                                                           coordSystem := #pathDataElementPreBuf.cmdCoordinates.coordSystem,
                                                           ...);

From here: the full 29‑command cmdType catalogue and every flag mode live in Commands and Flags above; to reshape any of these three paths interactively rather than read them off a table, try the Path lab.

§2.3 — Data structure

The PathData list

Every path LKinCtrl drives is one array — LKinCtrl_typePathData, a library UDT instantiated in a global DB. Each element is one command: a target, its dynamics and blending, and up to three Boolean and four LREAL flags to fire alongside it.

Top level

The structure that MovePath's pathData input points to. It holds the path's name and the command array itself.

NameTypeComment
pathDataNameString[LKINCTRL_LENGTH_OF_PATHDATA_NAME]Name of the PathData; shown as the active path data at MovePath.
LKinLangInterfaceLKinCtrl_typeAdvPointersInterface to the LKinLang application; pointers used to handle PathData as a ring buffer.
commands[1..LKINCTRL_NO_OF_PATHDATA_ELEMENTS]Array of LKinCtrl_typePathDataElementThe command list — one entry per array index, detailed below.

Inside one command entry — field reference

Every array element is an LKinCtrl_typePathDataElement. Fields not relevant to a command's cmdType are simply left at their defaults.

FieldTypeComment

Worked example — linear move with flags

// illustrative field values, not a manual screenshot
commands[3].cmdType                      := 1     // absolute linear
commands[3].cmdName                      := 'ToPick'
commands[3].point                        := 2     // resolved from Point Table
commands[3].cmdCoordinates.coordSystem   := 1     // OCS1
commands[3].cmdParameters.pathDynamics.velocity   := -1.0  // TO default
commands[3].cmdParameters.bufferMode     := 2     // blend, lower speed
commands[3].cmdParameters.transitionParameter[1]  := 40.0  // mm
commands[3].setFlags[1].flag             := 2
commands[3].setFlags[1].flagMode         := 1     // SET_BEFORE_AND_NO_RESET
commands[3].setFlags[2].flag             := 4
commands[3].setFlags[2].flagMode         := 21    // RESET_AFTER

Worked example — circular, CircMode 1

// illustrative field values, not a manual screenshot
commands[4].cmdType                                    := 3      // absolute circular
commands[4].cmdParameters.circleParameters.circMode     := 1      // auxPoint = centre
commands[4].cmdParameters.circleParameters.auxPoint[1]  := 250.0  // centre, coord. 1
commands[4].cmdParameters.circleParameters.auxPoint[2]  := 0.0    // centre, coord. 2
commands[4].cmdParameters.circleParameters.arc          := 180.0  // opening angle
commands[4].cmdParameters.circleParameters.pathChoice   := 0      // positive / CCW
commands[4].cmdParameters.circleParameters.circlePlane  := 2      // X-Y plane

Point reference §3.2

Rather than writing coordinates inline, a command can reference a row of the Point Table attached at MovePath. The reference is resolved to real coordinates when the command is copied into the internal buffer.

  • Any value ≥ 0 in point is read as a point-table index. Exactly -1 means “no reference, use cmdCoordinates as written.”
  • An out-of-range point number throws an error — it is never silently ignored.
  • Circular commands can reference their AuxPoint the same way, via circleParameters.point.

Point references apply to: linear commands · circular commands with aux-point mode 0 or 1 · the pick-and-place command · MoveDirect / sPTP · the OCS frame command · the UCS frame command · Define Tool.

End of path §3.1

A command with cmdType = -1 marks the end of the list. Nothing after it is executed — unused trailing array elements can simply stay at their default cmdType of −1.

Configuration §2.3.2

PathData is a UDT: define a DB variable of type LKinCtrl_typePathData, fill it either by pointing and clicking in the DB view or by writing SCL networks ahead of the MovePath call (a running command-index variable, incremented after each definition, keeps the array order easy to reorder by dragging networks). Run that definition logic once — e.g. on PLC startup — not every cycle.

Library constantGovernsValue
LKINCTRL_NO_OF_PATHDATA_ELEMENTSLength of the commands array per PathData.20
LKINCTRL_LENGTH_OF_PATHDATA_NAMECharacter length of pathDataName.20

Both are library constants: raise LKINCTRL_NO_OF_PATHDATA_ELEMENTS for longer paths, or the name length if pathDataName needs to carry more than 20 characters.

§3.1–3.16 — Command reference

Command catalogue

The cmdType field on a PathData entry selects one of 29 command types across 12 families, plus the measurement flag that rides along on a motion command. Filter by family or search across names, parameters and rules.

§3.10 — Flags

Flags

Every command entry can drive actuators through the path itself: up to three Boolean setFlags and four LREAL ValueFlags per command, timed by a flagMode against that command's own motion.

Principle of operation

The setFlags/ValueFlags arrays on a command entry refer, by index, into the Boolean flags and LREAL valueFlags InOut arrays at the LKinCtrl_MC_MovePath interface — typically wired straight to output signals. The default value for every flag entry is -1, which triggers nothing: it neither sets nor resets. Explanations below refer to setFlags only; the mechanism is identical for ValueFlags, except that a value is written instead of a bit being set.

ConstantDefaultGoverns
LKINCTRL_NO_OF_CMD_SETFLAGS3Boolean setFlags configurable per command entry.
LKINCTRL_NO_OF_CMD_VALUEFLAGS4LREAL ValueFlags configurable per command entry.
LKINCTRL_NO_OF_LAST_SETFLAG10Highest index of the Boolean flags InOut array at MovePath.
LKINCTRL_NO_OF_LAST_VALUEFLAG10Highest index of the LREAL valueFlags InOut array at MovePath.
Notice Flags are indexed flags[0..LKINCTRL_NO_OF_LAST_FLAG] — because the array starts at 0, the actual number of available flags is one more than the constant's value.
Notice If two PathData structures blend into one another, give each a different pathDataName so their flag activity can be told apart.

Reset. The flags InOut arrays reset automatically at the start of a PathData and on MovePath's done signal. Set the global tag LKINCTRL_DISABLE_FLAG_RESET to disable that automatic reset.

Flag modes

The flagMode on a setFlags/ValueFlags entry chooses when the flag is set or reset relative to its command, and whether execution should wait for an external acknowledge.

ModeConstantBehaviour

Subtleties worth knowing

Caution Combining flagMode 5 with flagMode 11, 13 or 15 on the same command can interlock that flag so it can never be reset — avoid programming this combination.
Notice Acknowledging a ValueFlag (modes 5, 15, 25) means writing it back to its default LREAL value, -1.0. Mode 26 is the exception: it is acknowledged by writing any value other than -1.0.
Note For modes 10 and 22, remember that a command's “end” is where the next command's blending radius (transitionParameter[1]) begins. A reported remainingDistance of 0.0 therefore does not always mean the literal programmed target has been reached.
Note Flags reset automatically on a new rising edge at execute and on MovePath's done signal — but not on a stop. An actuator held by a flag (a vacuum gripper, say) stays engaged if the path motion is stopped mid-command; that has to be handled deliberately in the user program if it isn't wanted.
§3.7 — Conveyor tracking

Conveyor tracking

A track-conveyor command couples an OCS to a moving belt so the kinematics can approach, follow and depart a product without it ever standing still.

How synchronisation works

Tracking uses an OCS frame that MovePath updates continuously from a leading value — the conveyor's own position. The OCS origin becomes, and stays, equal to the moving product's position.

Conveyor tracking schematic A kinematics TCP synchronising its OCS to a point riding on a moving conveyor belt. belt motion — TOConveyor.Position ConveyorBeltOrigin OCS (tracked) kinematics TCP objectPosition = TOConveyor.Position − initialObjectPosition

3.7.1 Track conveyor belt — prerequisites & configuration

  • Every conveyor axis must be listed on the TO Kinematics conveyor-tracking tab.
  • A conveyor parameter set must be configured at the MovePath input Configuration.ConveyorParameter: the belt axis technology object, ConveyorBeltOrigin (position of the measuring system that triggers on a detected product) and InitialObjectPosition (the measured position value at that trigger). Only the X component of initialObjectPosition may be non-zero — all other coordinates must be 0.0.
  • In the PathData: set cmdType = 10, choose the OCS to track in cmdCoordinates.coordSystem (1–3 only), and select the configured set via cmdParameters.conveyorParameters.conveyorParaNo.

Once the command executes successfully, that OCS is coupled to the belt; the kinematics synchronises with it on the next command that targets the same OCS.

Note Up to FW 3.0.x, dynamic adaption must be deactivated for every command during conveyor tracking.
Note sPTP commands are not allowed while conveyor tracking is active.

Blending restrictions

Up to FW 3.0.x, blending is not possible:

  • Into a motion job that completes the tracking at the conveyor (“In Sync” → “Sync Off”).
  • From a motion job moving into the first position of the tracked OCS, into the subsequent motion job in that same tracked OCS (“Sync On” → “In Sync”).
  • From a motion job exiting tracking to a subsequent motion job that re-enables tracking on another OCS (“Sync Off OCS1” → “Sync On OCS2”), if the second command executes while the first is still active.

Stopping & desynchronising

Synchronisation ends the moment a command in WCS, or an untracked OCS, executes. A dedicated desync command can only be an absolute linear or absolute circular (circMode 0) command.

Warning MC_GroupStop does not desynchronise from a conveyor. If tracking is active when a GroupStop is triggered, the kinematics keeps moving synchronously with the belt.

For automatic desync on stop or error, set Configuration.stopMode to 10 or 11:

stopModeStop dynamicsDesynchronisation
0Current dynamicsNone
1Maximum dynamicsNone
10Current dynamicsAfter stop
11Maximum dynamicsAfter stop

3.7.2 Desynchronise conveyor

cmdType = 50 desynchronises from the conveyor with only a small movement: internally, a linear command runs to the current TCP position.

§4 — Standalone function blocks

Standalone function blocks

Five blocks work outside a PathData list, for group housekeeping, manual jogging and a self-contained pick-and-place move — the same motion sequence that cmdType 11 wraps for use inside a path.

LKinCtrl_MC_GroupPower FB 35021

Enables or disables every axis interconnected to the attached axesGroup in one call — equivalent to fanning MC_Power out across the whole kinematics group.

enableIN Bool — TRUE enables the axes, FALSE disables them.
startModeIN Array DInt — per axis: 0 not position controlled, 1 position controlled.
stopModeIN Array Int — per axis: 0 emergency stop, 1 immediate stop, 2 stop with max dynamics.
axesEnabledOUT Bool — TRUE once every axis in the group is enabled (or disabled).
busy / errorOUT Bool — standard PLCopen status.
diagnosticsOUT struct — status constants in §6.4.1.
axesGroupIN_OUT TO_Kinematics.

LKinCtrl_MC_GroupReset FB 35023

Resets every TO axis on the axesGroup and the TO_Kinematics object itself — the group-level equivalent of MC_Reset, used to acknowledge errors or reinitialise.

executeIN Bool — rising edge starts the reset.
restartIN Array[1..7] Bool — per axis: TRUE reinitialises the technology object, FALSE does not.
done / activeOUT Bool — done once the group is successfully referenced; active while in control.
commandAbortedOUT Bool — TRUE if another command aborted this one.
busy / errorOUT Bool — standard PLCopen status.
diagnosticsOUT struct — status constants in §6.4.2.
axesGroupIN_OUT TO_Kinematics.

LKinCtrl_MC_GroupHome FB 35022

References every TO axis interconnected to the axesGroup, with the same homing-mode options as MC_Home applied per axis.

executeIN Bool — rising edge starts homing.
positionIN Array LReal — reference positions / orientations per axis.
modeIN Array Int — homing mode per axis.
done / activeOUT Bool — done once the group is successfully referenced.
commandAbortedOUT Bool — TRUE if another command aborted this one.
busy / errorOUT Bool — standard PLCopen status.
diagnosticsOUT struct — status constants in §6.4.3.
axesGroupIN_OUT TO_Kinematics.

LKinCtrl_MC_JogFrame FB 35010

Manual jogging in Cartesian X/Y/Z/A/B/C, continuous or incremental, plus positioning to a target — interpolated or via sPTP — in any supported coordinate system and with any of up to three tools.

jogForward / jogBackwardIN Bool — edge starts continuous or incremental jog; falling edge stops it.
jogToPosition / jogSPTPIN Bool — hold to move (interpolated / sPTP) to targetPosition; falling edge stops early.
jogDirectionIN USInt — 1 X · 2 Y · 3 Z · 4 A · 5 B · 6 C · 7 Z-axis about A · 8 Y-axis about B · 9 X-axis about C.
jogModeInc / jogIncrementIN Bool / LReal — incremental vs. continuous, and the increment distance.
targetPositionIN struct — target for jogToPosition / jogSPTP.
coordSystemIN DInt — 0 WCS · 1–3 OCS · 100 MCS · 101 JCS (KinPlus only).
linkconstellationIN DWord — target joint-position space, jogSPTP only.
toolIN DInt — 1–3.
dynamicsIN struct — jog velocity / acceleration / deceleration / jerk.
done / active / errorOUT Bool — standard PLCopen status.
statusOUT Word — constants in §6.3.
remainingDistanceOUT LReal — distance-to-go while jogging incrementally or to a target.
axesGroupIN_OUT TO_Kinematics.
Note In MCS or JCS, jogging respects joint limits and software limit switches and stops there.
Notice A jog command triggered while another motion job is in progress is not executed; and if more than one jog input is set at once, no movement starts and any ongoing jog is stopped.

LKinCtrl_MC_MovePickAndPlaceLinear FB 35026

Wraps a full linear pick-and-place motion — optional start vector, transition, optional target vector, optional conveyor tracking — behind one PLCopen-style call. It is the block that cmdType 11 runs internally; everything here also applies to that PathData command (§3.15).

Motion sequence

  1. ·Enable tracking on the target coordinate system (optional).
  2. 1Linear motion along the start vector (optional) — commandStep = 1.
  3. 2Blending into the transition motion (optional) — commandStep = 2.
  4. 3Transition motion — commandStep = 3.
  5. 4Blending into the target vector (optional) — commandStep = 4.
  6. 5Linear motion along the target vector (optional) — commandStep = 5.

Orientation only moves during the transition motion (steps 2–4) — never in the linear start or target vector. On a 2D+A or 3D+A kinematics, directionA can force which way that orientation turns.

Interface essentials

executeIN Bool — rising edge starts the sequence; FB status must read 16#7000 first.
position / coordSystemIN — target X/Y/Z/A/B/C and its frame: 0 WCS, 1–3 OCS.
startPosition / startCoordSystemIN — explicit start point; startCoordSystem <0 uses the actual current position.
directionAIN DInt — 1 positive · 2 negative · 3 shortest (2D+A / 3D+A kinematics only).
startParameter / targetParameterIN LKinCtrl_typePnPParameter — the two vectors, see below.
conveyorTrackingIN LKinCtrl_typePnPConveyorTracking — see below.
dynamicsIN LKinCtrl_typePnPDynamics — path / orientation dynamics and adaption mode.
bufferMode / transitionParameterIN — blending into this sequence from the previous command.
done / busy / active / commandAborted / errorOUT Bool — standard PLCopen status.
commandStepOUT DInt — 0 not active, else 1–5 as above.
remainingPathLengthOUT LReal — valid only once readyForNextCommand = TRUE.
readyForNextCommandOUT Bool — TRUE once every command is buffered; gates the next FB call.
status / diagnosticsOUT — constants in §6.2.
axesGroupIN_OUT TO_Kinematics.

Command buffering

Motion commands queue one after another, starting from the latest target position before the FB was triggered (or the current position, if nothing was moving). Only buffer a following MC command once readyForNextCommand = TRUE, so the order stays correct. remainingPathLength only reports a meaningful value once that output is TRUE, and it is not corrected for later internal shortening — e.g. blending or (de)synchronisation — so it may not reach exactly 0.

Conveyor tracking

Set conveyorTracking.enable = TRUE to couple the target OCS (coordSystem) to a belt axis before the motion starts, using the block's own axis, origin and initial-position inputs.

FieldTypeComment
enableBoolTRUE establishes tracking with this command's execution.
conveyorBeltAxisDB_ANYConveyor belt axis DB.
conveyorBeltOriginTO_Struct_Kinematics_FrameFrame at the conveyor's origin.
initialObjectPositionTO_Struct_Kinematics_FrameObject position on the belt at trigger time — X only, as in §3.7.1.
  • Not established if the target coordinate system is the WCS.
  • If the target OCS is already tracked, no new tracking starts — but initialObjectPosition is still applied to adapt the target position, so no manual adjustment is needed.
Notice If an externally issued MC_TrackConveyorBelt is already queued (busy, not yet done) when internal tracking is also requested, the outcome is undefined — the FB cannot detect this, so it must be prevented in the user program.

Blending into the sequence

  • bufferMode = 1: waits for the previous motion and an empty queue before buffering.
  • bufferMode = 2 or 5: buffers as soon as the previous sequence's last command is active.
Note Blending into the command is, by default, only possible with no start vector and no motion between two tracked OCS. To blend in either of those cases too, an explicit start position and coordinate system are required (startCoordSystem ≥ 0).

Start & target vector parametrisation

Both vectors share the same four fields, in startParameter / targetParameter (type LKinCtrl_typePnPParameter):

FieldComment
direction[1..3]X/Y/Z direction of the vector, always pointing away from start or target; normed internally. All-zero means no vector at all.
workingHeight≤0 no vector · >0 length, meaning set by LKINCTRL_PNP_WORKINGHEIGHT_MODE: mode 1 (default) is the complete working height including the blending part; mode 2 is the linear length alone.
transitionArea<0 uses the axesGroup's max blending radius (not with mode 2) · = 0 standstill at the vector's end · >0 blending distance · ≥ workingHeight collapses to pure blending, no linear component (mode 1 only).
dynamicsFactorPath-velocity scaling factor along this vector, 1–200%.
Notice With FW 3.0.x, if an OCS with active conveyor tracking is part of the motion, both transitionArea fields must be 0.0 and dynamics.dynamicAdaption must be 0 — no blending above the start or target point, no dynamic adaption.

No vector at all (workingHeight = 0 or direction = [0,0,0]) makes the block behave like a plain MC_MoveLinearAbsolute to position.

Start position & coordinate system

Setting startPosition / startCoordSystem explicitly is required whenever blending into the command (bufferMode > 1) is combined with a start-vector definition, or with a change between two tracked OCS. Otherwise the default (startCoordSystem = -1, use the actual position) is fine.

Worked example — wait → pick → place → wait

A typical pick-and-place cell, both pick and place positions in conveyor tracking (values as documented for this sequence):

  1. 1Track OCS1 (pick side).
  2. 2Wait → Pick, in OCS1: vertical approach/depart, 200 mm working height, 100 mm blending, velocity reduced to 50%. Start parameter left empty — motion runs straight to the vector end with TO default dynamics.
  3. 3Track OCS2 (place side).
  4. 4Pick → Place, in OCS2: vertical vector, 100 mm length, dynamics factor 75%, fully blended (transitionArea = workingHeight) — both start and target vector defined.
  5. 5Place → Wait, in WCS: only the start vector defined, no target vector — no automatic tracking needed since the target is in WCS.

conveyorTracking.initialObjectPosition is updated before every execution of the sequence, from the current measured object position.

Error handling

Acknowledge a present error by setting execute = FALSE. If the block gets stuck between status 16#7000 and 16#8000, abort it with MC_GroupStop. Motion-command errors (status 16#8701–16#8720) carry the underlying MC command's error in subFunctionStatus — see the TO documentation. Command-creation errors (status 16#8601) are broken down in the Error handling section below.

§6–7 — Error handling & PLC tags

Errors, status & configuration tags

Every status and error identifier the library's blocks raise, grouped by the block that raises it — plus the PLC tag tables that configure and enumerate the library.

Status & error identifiers

Always read a block's diagnostics output for the full picture: it names the PathData command and internal state a MovePath error occurred in, on top of the status word itself.

Raised byIdentifierValueKindMeaning

LKinCtrl_Configuration §7.1

Application-level settings — sizes, name lengths and a handful of behavioural switches. These values may be changed to suit the project.

TagDefaultGoverns
LKINCTRL_LENGTH_OF_CMDPOINT_NAME30Length of a point name.
LKINCTRL_LENGTH_OF_OFFSET_NAME20Length of an offset (tool) name.
LKINCTRL_LENGTH_OF_PATHDATA_NAME20Length of a PathData name.
LKINCTRL_LENGTH_OF_TO_NAME30Length of technology-object names.
LKINCTRL_NO_OF_CMD_SETFLAGS3Boolean flags configurable per command.
LKINCTRL_NO_OF_CMD_VALUEFLAGS4LREAL flags configurable per command.
LKINCTRL_NO_OF_CONVEYOR5Number of configurable conveyor sets.
LKINCTRL_NO_OF_LAST_SETFLAG10Highest index of the Boolean flags array at MovePath.
LKINCTRL_NO_OF_LAST_VALUEFLAG10Highest index of the LREAL valueFlags array at MovePath.
LKINCTRL_NO_OF_OFFSETS3Number of configurable tool-offset sets.
LKINCTRL_NO_OF_PATHDATA_ELEMENTS20Length of the PathData command array.
LKINCTRL_NO_OF_PATHS5Number of paths.
LKINCTRL_NO_OF_POINTS_AT_POINT_TABLE30Number of points in the Point Table.
LKINCTRL_NO_OF_SEQ_EXECUTE_CMDS1Commands buffered per call after the first cycle (§5.1).
LKINCTRL_NO_OF_START_EXECUTE_CMDS1Commands buffered on the first cycle (§5.1).
LKINCTRL_NO_OF_ZONES10Number of zone definitions.
LKINCTRL_SPTP_EXECUTION_STATUS_OUTPUT00 regular time status · 1 inverted · 2 approximate Cartesian distance.
LKINCTRL_DISABLE_FLAG_RESETFALSETRUE disables the automatic flag reset at execute / done.
LKINCTRL_NO_OF_CHANNELS0Number of channels − 1; relevant to the HMI part only.
LKINCTRL_PNP_WORKINGHEIGHT_MODE11 workingHeight is the complete height · 2 linear length only.

LKinCtrl_Constants §7.2

Fixed values used to configure PathData commands by name instead of magic numbers. cmdType and flag-mode constants are listed inline in the Commands and Flags sections above; the remaining ones are gathered here.

TagValueGoverns
LKINCTRL_PATHDATA_TYPE_REDUCED / _NORMAL / _ADVANCED1 / 2 / 3PathData type constants.
LKINCTRL_FM_DISTANCE_TOLERANCE0.01Tolerance used by flagMode 10.
LKINCTRL_NO_OF_VALID_BITS6Number of valid bits in ParameterValid.
LKINCTRL_NO_OF_PATHDATA_PREBUFFER_ELEMENTS5Number of PreBuffer elements.
LKINCTRL_NO_OF_SETFLAGS_BUFFER_ELEMENTS15Double the PreBuffer element count.
LKINCTRL_PI3.14159…Constant value for π.
LKINCTRL_COMP_LEFT / _RIGHT1 / 2Tool-radius compensation side.
LKINCTRL_OUTER_CORNER / _INNER_CORNER1 / 2Linear/linear intersection type for contour offset.
LKINCTRL_CIRCMODE_GCODE3circMode value used in G-code notation.
LKINCTRL_CS_NO_OF_FIRST/LAST_USER_FRAME11 / 15Index range of the five user frames (USER_FRAME_1…5).
LKINCTRL_MEAS_CMD_WO_ACK / _WITH_ACK1 / 2Measurement-command mode (§3.16).
LKINCTRL_NO_OF_PATHDATA_ELEMENTS_ADVANCED / _REDUCED20 / 10Legacy PathData array lengths.
LKINCTRL_FIRST/LAST_INDEX_INFO_BUFFER−10 / 20Index range of the buffered-commands info output array.

MC_Constants §7.3

Named constants for the same numeric settings TO Kinematics motion commands use directly — for configuring PathData or a standalone FB call without magic numbers.

TagValueGoverns
BM_BUFFERED / _BLENDING_LOW / _BLENDING_HIGH1 / 2 / 5bufferMode.
DA_DEFAULT / _DEACTIVATED / _WITH_VARIABLE_LIMITS / _WITH_CONSTANT_LIMITS−1 / 0 / 1 / 2dynamicsAdaption.
SM_ACTIVE_DYNAMICS / _MAX_DYNAMICS0 / 1Stop mode dynamics.
PC_POSITIVE / _LONG_RUN_POSITIVE / _LONG_RUN_NEGATIVE0 / 2 / 3pathChoice.
CP_XZ / _YZ / _XY0 / 1 / 2circlePlane / mainPathPlane.
CM_BORDER / _CENTER / _RADIUS0 / 1 / 2circMode.
IM_ACTIVE_DYNAMICS / _MAX_DYNAMICS0 / 1Interrupt mode dynamics.
DIRA_POSITIVE / _NEGATIVE / _SHORTEST1 / 2 / 3orientationDirection / directionA.
Field notes

What bites people first

A dozen things the manual flags explicitly, or that fall out of how the mechanism actually works, gathered in one place.

Blending doesn't apply at Define Tool / Set Tool §3.8.3–3.8.4

Both commands force the kinematics to standstill first; MovePath drains the motion queue automatically to get there. bufferMode is irrelevant — there is no blending into either command.

No blending after a measurement command §3.16

The measurement flag aborts its motion command mid-flight on a sensor edge. Whatever comes next cannot blend into that abort point.

Pick-and-place blending needs an explicit start point §3.15, §4.5

bufferMode 2/5 only blends into the sequence when there is no start vector and no cross-OCS tracking change — or when startCoordSystem is set explicitly to cover those cases.

Conveyor tracking has its own blending exceptions §3.7.1

Up to FW 3.0.x, three specific transitions can't blend: finishing tracking, moving straight into a freshly tracked OCS, and switching tracking from one OCS to another back to back.

Interpolated motion and sPTP report progress differently §3.5

Linear and circular commands expose remainingDistanceActCmd. sPTP has no path length to measure, so it exposes a time-based executionTimeStatus (0.0–1.0) instead. Only sPTP can change link constellation — a continuous-path move can't leave the current axis-position space.

Coordinate system and tool decide where a point actually is §3.8

The same Cartesian fields resolve differently under WCS, OCS[1–3], MCS (100), JCS (101) or a UCS — and switching the active tool moves the TCP with it. A rotated UCS (A, B or C ≠ 0) also rejects circMode 1 and 2 outright.

Conveyor tracking has real prerequisites §3.7.1

The axis must be listed on the TO Kinematics conveyor-tracking tab and have a parameter set configured at MovePath's Configuration input. initialObjectPosition only accepts a value on X. sPTP commands are rejected outright while tracking is active.

MC_GroupStop does not desynchronise §3.7.1, WARNING

A GroupStop during active tracking leaves the kinematics still riding the belt. Use stopMode 10/11 for automatic desync on stop, or an explicit cmdType 50.

flagMode 5 plus 11/13/15 can interlock a flag §3.10.2

Combined on the same command, a wait-for-acknowledge mode and an auto-set-after mode on the same flag can leave it permanently unable to reset. Don't combine them.

remainingDistance = 0.0 isn't always the target §3.10.2

flagModes 10 and 22 measure to where the next command's blending radius begins, not the literal programmed point.

Flags survive a stop, but not a fresh start §3.10.1

A stopped path leaves flag-driven actuators exactly as they were — a gripper keeps holding. Only a new rising edge at execute, or MovePath's own done signal, resets the flags.

A point reference ≥ 0 is taken literally §3.2

An invalid point number throws an error rather than being ignored. Use exactly -1 to mean “no reference.”

Relative OCS shifts stack only on the same CS §3.14

Shifting a different coordinate system silently resets the previous shift. And insert a linear move to the CS origin before any circular command that immediately follows a shift.

Drawn from the LKinCtrl V5.3 manual (Siemens Industry Online Support, Entry ID 109755891, 04/2026) and its Getting Started manual. This page is a reading aid built for quick lookup — not a substitute for the manual, which remains the authority for anything safety-relevant or version-specific.