SyncTwinTECHNOLOGIES
Solution · offline programming

A robot program — without stopping the cell

The path is written on the cell twin while the cell keeps working. What goes to start-up is a program that has already passed plunge and collision checks.

What it is

The cell works while its next program is being written

When programming from a pendant the cell stands still: the robot is led point by point until it remembers the path. Every new part is a new stop.

Offline programming moves this work to the cell’s twin. The robot path is written in the browser using places already in the twin, checked before start, and only then goes to the cell — the axes are driven by our control.

The process engineer names the intent — transfer, flip, weld a seam. The platform derives points, poses, axis order and checks. Guesses where they would cost a part are replaced by a refusal with a reason.

Without stopping the cell

The program is prepared while the cell produces the current part.

Verified before start

Air cuts, plunges, collisions and fit — against one cell model.

Portable

The path text does not depend on the coordinates of a specific cell: places come from its twin.

How the work goes

Five steps to start-up

  1. Cell placesVice, turnover unit, pallet, welding table — by name; coordinates live in the twin and are measured by teaching.
  2. Program“New program” — the “motion” kind and the machine are chosen once; the list splits machines by suitability.
  3. Path in verbsTransfer, flip, orbit, seam: the lab — code on the left, the cell in 3D on the right, recalculation on every change.
  4. ChecksFindings are split into errors, warnings and notes; an error locks the start.
  5. RunVirtual axes first, then drives — the mode is chosen explicitly, the hardware’s answer is visible on screen.
Cell twin

What the program does not hard-code but takes from the twin

WhatSourceWhy so
Cell placesTwin; measured by teachingThe program names the place; no such place — a refusal listing what exists
Start pointTwinThe program starts and ends at it — so it can be put into the procedure in any order
Program baseTwin; taughtNumeric points count from the base; a move by place name does not follow the base
Jaw span, stick-out, valve portTooling datasheet and current setupNot duplicated in the program text and not guessed
PartSize, place, grip side — named by the authorGrip point, top, centre and span are derived from the size

Having to edit the text for a cell means knowledge about the cell has leaked into the intent. The edit is made in the twin, and the program stays the same.

Checks before start

What gets caught while the cell keeps working

One set of maths

Air cuts, plunges, collisions and fit are calculated over one mechanism description. A motion run is judged to the end of the program, not to the first block.

Three levels of findings

An error locks the start. A warning is a legitimate intent that must not go unmentioned. A note is for information.

“Not verified” instead of zero

Unknown stick-out is named as such. Sending is blocked by a slot without a stick-out of named origin — datasheet or measurement.

Situation in the programReaction
Flip with a top griprefusal — a side grip is needed
The path welds but the arc output is not boundrefusal — the jaw valve would twitch instead of the arc
The arc is lit and not extinguishedrefusal — the torch would travel to the start point while burning
Start point not setwarning — start from wherever the arm stands now
The path ends with closed jawswarning — legitimate if the part is handed on

The full list of verbs and refusals — “Robots and tooling”.

Robot and positioner

Each axis has one owner at any moment

The positioner is an external seam axis

When the positioner turns the part under the torch, it is part of the cell’s seam program. With a two-axis positioner the table makes a circular seam while the torch stays still.

Changing the owner — only at rest

A robot can make a seam with a motion program and move a part with an automation block, but not at the same time: these are two program steps with rest between them.

Why this rule

Two programs writing one axis fight over it. The limitation is accepted deliberately: there is no taking over an axis on the move.

Start and answer

From a verified program to arm motion

StageWhat happens
Set up and sendThe test bench and axis profiles are made current; if the test bench is taken by a project, the platform asks whether to unbind it
StartThe configuration is generated from the twin and sent to the box; each step of the chain is a test bench answer
HomeOn absolute encoders — no search; without homing automatic mode does not start
ProgramExecuted step by step; the monitor shows coordinates and 3D from actual data
StopOne command in every window

Program header

Carries the orientation convention, tool axis direction, grip method and gripper port — what cannot be recovered from coordinates.

Virtual axes

No bus and no torque: the program and block order are checked without risk. A green run here does not prove the axis will move on hardware.

Drives

Torque is applied only inside a motion step; the hardware’s answer — position, following error, status word — is on screen.

What the process engineer gets

A program you can put into the cycle

  • Start and end — at the start pointThe program is put into the cell procedure in any order.
  • Findings by levelAn error locks the start; warnings and notes are for information.
  • “Not verified” instead of zeroAn unknown tool stick-out is named as such, not taken as zero.
  • One program — different armsPlaces come from the twin of the specific cell; the path text stays the same.

The 6-axis arm is at an experimental maturity level; the program on your cell is worked out in the implementation.

For roles

Who gets what

Robot programmer

Writes intent with verbs, not points from a pendant; refusals come with a reason and numbers.

Process engineer

Changes the part size or place — the path is recalculated without rewriting.

Area manager

A new part does not stop the cell for teaching.

Integrator

The program is ready before the robot arrives and verified on the twin of the customer’s cell.

Models in the library

Robots, positioners and gripper — per the manufacturer’s datasheet

Geometry, axes and limits of the models are taken from the manufacturer’s datasheet or STEP. Every model is marked “per datasheet”: on the bench their axes run on virtual axes.

Manufacturer · modelKindAxesMark
KUKA KR16arm6per datasheet
CRP RA18-25arm6per datasheet
CRP RH15-15-HPmilling robot6per datasheet
CRP RP32-180palletiser4per datasheet
CRP RS04-03SCARA4per datasheet
CRP WB1K-500, WB1S-750, WB2S-250, WB3S-500welding positioners1–3per datasheet
CRP WD250-6000linear trackseventh axisper datasheet
MotoPos D500tilt-rotate positioner2per datasheet
Robotiq 2F-85two-finger gripperone actuatorper datasheet
KUKA KR16 + CRP WB2S-250composite kind: arm and positionerarm 6 + positionerper datasheet

Our control drives the axes

The robot model in the twin moves by the platform’s program; the axes are driven by our control, on the bench — virtual axes.

No post-processors

There are no post-processors into robot languages: the program is not exported to the manufacturer’s robot controller, and we do not claim control of that controller.

Your model

A model that is not in the library is assembled from the manufacturer’s STEP; scope and timing — as agreed during the implementation.

Discuss an implementation

Describe the cell and the part — we will build it in the twin, write the program and propose an R&D stage with price and timeline.

Request access
Next step

Discuss an implementation

Describe the unit or line — we will tell you what we will verify and in what time. Target indicators are fixed in the implementation specification.

Request access

Implementation →

Request access