DReS Robot Cell Simulator - Simulate the Whole Cell: All Robots, Real Time, Motion Planner (YouTube, Englisch)
DReS Robot Cell Simulator - Die ganze Zelle simulieren: alle Roboter, Echtzeit, Bewegungsplaner (YouTube, Deutsch)

Auf allen Robotern ausführen Simulation

Die Registerkarte Simulation startet dasselbe Programm (z. B. Folge 12) gleichzeitig auf allen Robotern der Zelle. Loops wiederholt den Durchlauf, Stop on breakpoints verwendet die Haltepunkte der Programme (siehe Programmablauf), Stop all stoppt alle Roboter. Derselbe Befehl steht unter Simulation → Run program on all robots.... Program: Typ Folge oder UP und die Nummer (1..9999). Loops: 1..999. Mit dem SPS-Programm ist das Feld gesperrt und zeigt die Zyklen des Blocks Start des SPS-Programms. Während des Ablaufs zeigt der Zähler daneben n / m (der Roboter, der am weitesten zurück ist). Speed: 0..400 % der Echtzeit, mit dem Schieberegler, dem Feld und den Knöpfen 25 / 50 / 100 / 200 / 400 %. 0 % = Pause. Der Knopf Pause setzt die Geschwindigkeit auf 0: die Roboter, die Halte bei Befehlen und die Uhr der Station stehen. Resume (derselbe Knopf) fährt mit der Geschwindigkeit vor der Pause weiter. Start in zwei Phasen: die Roboter bereiten zuerst den Ablauf vor (der Bahnplaner berechnet die Bahn des ersten Durchlaufs und den Start der nächsten), die Simulationsuhr steht dabei; sind alle Roboter bereit, startet die Uhr und alle Roboter fahren zusammen los (Konsole: Alle Roboter sind bereit ... Vorbereitung x s, nicht in der Simulationszeit; SmartPad: Bewegung wird vorbereitet / Bereit). Vorbereitung im Hintergrund: nach dem Laden einer Studie oder Simulation, einer Änderung des SPS-Programms oder des Programms dieser Registerkarte werden die Programme, die die Roboter fahren (Folge und die daraus aufgerufenen UP), im Hintergrund geparst, eine Datei nach der anderen, die Szene bleibt bedienbar (Konsole: Simulation wird vorbereitet ..., kleines Fenster mit Fortschrittsbalken in der Ecke). Der Start nimmt sie dann aus dem Speicher (Konsole: Roboter vorbereitet in x s: n Programm(e) aus dem Speicher, m jetzt geparst); ein im SmartPad oder Editor geändertes Programm wird neu geparst, Makros beim Start. Bis zu 12 Roboter gleichzeitig; jeder Roboter läuft in einem eigenen Thread, der Rechner braucht daher mindestens Roboter + 1 logische Prozessoren – siehe Ablauf, Prozessor und Genauigkeit. Der grüne Knopf SPS fährt die Zelle mit der simulierten Stations-SPS: Folgenstart, Freigaben der Station und Zyklen kommen aus dem SPS-Programm – siehe Stations-SPS und SmartPad. Schnellstart (Fast Run) – unter dem Knopf SPS eine Reihe von Knöpfen, die ein festgelegtes Programm sofort auf allen Robotern starten, mit der angegebenen Anzahl von Durchläufen und ohne das SPS-Programm (der Knopf SPS und die Felder des Reiters bleiben unverändert; das nächste Auf allen Robotern ausführen läuft wieder mit der SPS). Typisch: Folge 125, um alle Roboter vor der Simulation mit der SPS in HOME zu fahren (nach dem Laden einer Zelle stehen die Roboter nie in HOME). Die Knöpfe stehen in template/RCS/fast_run.xml von DReS, ein Element je Knopf: <FastRun version="1"> <Button program="folge123" loops="1"/> <Button program="folge125" loops="1" text="HOME" tooltip="Alle Roboter in HOME"/> </FastRun> program – Folge oder UP mit Nummer (folge125, Folge 125, up42), loops – Anzahl der Durchläufe (Standard 1), text / tooltip – optional. Passen die Knöpfe nicht in eine Zeile, wird umgebrochen; ohne Knöpfe ist die Reihe ausgeblendet. Eine geänderte Datei wird sofort neu gelesen; Rechtsklick auf die Reihe: Datei öffnen / Knöpfe neu laden. Die Optionen des Reiters (Verriegelungssignale, Programmregeln, Geschwindigkeit) gelten wie bei Auf allen Robotern ausführen. Fast Run läuft immer ohne das SPS-Programm, auch wenn der Knopf SPS eingeschaltet ist; Stop on breakpoints gilt auch hier.

Alle Roboter der Zelle während des Ablaufs von Folge 81

Ende der Simulation: endet eine Stationssimulation, meldet das Fenster Simulation beendet Die Simulation der Station ist beendet. Das Fenster ist nicht modal – Szene, Konsole und die anderen Fenster bleiben bedienbar, solange es offen ist. Mit Diese Meldung nicht mehr anzeigen (bis DReS neu gestartet wird) kommt es in dieser Sitzung nicht mehr; nach dem nächsten Start von DReS erscheint es wieder. Hat der Lauf Wettläufe gefunden, kommt stattdessen das Fenster Wettlauf gefunden (siehe Wettläufe: Vorschlag und Simulation beider Reihenfolgen). Es ist immer nur ein Fenster Simulation beendet offen: endet der nächste Lauf, während es noch offen ist, wird sein Text ersetzt (vorher konnten zwei oder drei Fenster gleichzeitig offen sein).

Über die Befehls-API gestartete Läufe (seit 2026-10-25): ein Lauf, ein Robustheitstest oder eine Simulation beider Reihenfolgen, den ein Skript oder der KI-Agent über die Befehls-API gestartet – oder angehalten – hat, endet ohne die Fenster Simulation beendet, Kollisionsgefahr in der Simulation, Wettläufe der Anforderungen, Wettlauf gefunden und Simulation beider Reihenfolgen - Ergebnis; ihr Text steht in der Konsole und in der API (status.lastRunMessages, run_data). Vorher blieben nach 50 Läufen und Stopps über die API etwa 90 Fenster offen. Eine über die API geladene Simulationsdatei öffnet auch nicht Simulation laden – Nicht wiederhergestellt. Mit den Schaltflächen des Fensters gestartete Läufe zeigen die Fenster wie bisher. Die Pause bei Kollisionsgefahr (Option Simulation bei Kollisionsgefahr anhalten) öffnet ihr Fenster mit Weiter auch bei einem Lauf der API.

DReS während einer Simulation schließen (seit 2026-10-25): DReS fragt nur einmal – das Fenster des Simulators fragt Die Simulation läuft. Die Simulation wirklich stoppen? (Vorgabe Nein; mit Nein bleibt DReS mit seinen Lizenzen offen). Die Frage Plugin important result von DReS kommt nur, wenn das Fenster des Simulators geschlossen (ausgeblendet) ist und noch eine Simulation oder ein Robustheitstest läuft. Wird DReS geschlossen, während eine Datei geladen wird, wartet das Schließen bis zum Ende des Ladens (Meldung in der Konsole), dann schließt sich DReS selbst. Die Uhr der Simulation (simTime in der API) steht, solange keine Simulation läuft, auch nach dem Öffnen des Simulators.

Meldung Simulation beendet am Ende einer Stationssimulation, mit dem Kontrollkästchen, das sie bis zum nächsten Start von DReS ausblendet

Wie die Roboter in der Simulation fahren

• Dieselbe Folge auf allen Robotern. Jeder Roboter fährt das Programm des Felds Program (z. B. Folge 81). Mit dem SPS-Programm kommt die Folge aus dem Stationsblock des Roboters (0 = die Folge des Felds); ein Roboter auf mehreren Stationen hat auf allen dieselbe Folgenummer. Es gibt keinen Lauf mit Folge 81 auf einem Roboter und Folge 82 auf einem anderen.
• Start und Reihenfolge. Ohne SPS starten alle Roboter zusammen (mit Start all together at 'Warte auf Folgenstart' in jeder Schleife erneut). Mit SPS gibt die Station den Folgenstart wie an der Anlage (Stationszeit, Wait-Blöcke, ein Wait nach einem Roboterblock verzögert nur diesen Roboter). Nach dem Start fährt jeder Roboter sein Programm für sich; die Reihenfolge der Roboter in einem gemeinsamen Bereich ergibt sich aus den Bewegungs- und Prozesszeiten und, mit Respect interlock signals, aus den Verriegelungen (ein Roboter wartet, bis der Partner den Bereich freigibt). Die Simulation zeigt eine Reihenfolge – die, die sich aus diesen Zeiten ergibt.
• UP-Aufrufe. UP calls: All calls führt jedes in der Folge aufgerufene UP aus, die Bedingung des Aufrufs wird nicht ausgewertet; Only = EIN nur die Aufrufe ohne Bedingung; Do not execute keine. Die Program rules Exclude UP / Exclude MAKRO lassen die angegebenen Programme aus (z. B. Serviceprogramme wie Kappenfräsen) – die Konsole nennt den Aufruf und seine Bedingung.
• Arbeitsbereiche (Kollisionsmatrix) werden aus allen Bewegungen der Folge und aller darin aufgerufenen UPs berechnet (bis zu 3 Ebenen, Bedingungen ignoriert, auch die ausgeschlossenen) – unabhängig von der Reihenfolge der Roboter. Die Kollisionsprüfung im Ablauf vergleicht die Bewegungen des Laufs mit diesen Bereichen.
• Robustheitstest. Er verwendet dieselbe Folge und dasselbe SPS-Programm; jeder Schritt ist ein neuer Lauf mit anderen Geschwindigkeiten, Halten oder Verzögerungen, so dass andere Reihenfolgen der Bewegungen derselben Folge auftreten. Die Option All UP calls des Tests führt jedes UP der Folge in jedem Takt aus (Regeln Exclude UP ignoriert, die Einstellungen dieses Reiters bleiben), der Verzögerungstest (MISSING) prüft jede Bewegung ohne Verriegelung gegen jeden Partner – Wie die Roboter im Robustheitstest fahren.

Fanuc-Programme in der Simulation

Ein Fanuc-Roboter (VW-Standard, siehe Fanuc-Roboter) fährt in der Simulation wie ein KUKA-Roboter: beim Laden des Archivs werden seine .ls-Programme in Ersatz-KUKA-Programme im Cache-Ordner übersetzt, und diese laufen mit denselben Optionen, demselben SPS-Programm, denselben Verriegelungen und Berichten. Die .ls-Dateien des Archivs bleiben unverändert.

Nicht simuliert – immer gemeldet in der Konsole des Ladens als Fehler oder Hinweis, nie stillschweigend ausgelassen:

• Bewegungen mit Offset ohne PR in der Zeile (der Versatz einer OFFSET CONDITION), Offset / Tool_Offset an Achspunkten oder mit einem PR ohne kartesischen Wert, nicht geteachte Punkte (*****), PR ohne Daten, Positionen außer Reichweite oder ohne Lösung mit der CONFIG des Punkts – der Roboter bleibt dort im vorherigen Punkt,
• LBL / JMP, Register R[], GO[], andere TIMER-Zeilen, PAYLOAD, CALL VW_USER und andere Zeilen erscheinen im Programm als Kommentare -- FANUC: ... --,
• Bewegungen mit Skip,LBL[] fahren bis zum Zielpunkt (Hinweis),
• Punkte außerhalb der aus dem Archiv gelesenen Achsgrenzen werden mit einem Hinweis simuliert.

Optionen des Ablaufs Simulation

• Start all together at 'Warte auf Folgenstart' (Standard: ein) – ein Roboter an Warte auf Folgenstart wartet, bis alle Roboter dort sind, dann starten alle zusammen, in jedem Durchlauf. Nur bei Loops > 1 und ohne SPS-Programm (mit der SPS kommt der Folgenstart aus dem SPS-Programm).
• Check interlock map (Verriegelungskarte prüfen) – eine Tabelle der im Programm verwendeten Verriegelungsbereiche auf allen Robotern: Beschreibungen (Langtexte), Partnerroboter und ob der Partner den Bereich ebenfalls nennt. Grün = OK, rot = fehlt.
• Show collision map (Kollisionskarte anzeigen) – eine Linie zwischen je zwei Robotern mit gemeinsamen Verriegelungsbereichen, über der Linie die Freigabeeingänge. Grün = alle Bereiche frei, rot = ein Bereich ist belegt; der Pfeil zeigt vom Roboter, der den Bereich hält, zum Roboter, den er sperrt. Lage: auf dem Boden, oben (unter den Statuslampen) oder am Roboterfuß. Die Bezeichnungen der Bereiche stehen entlang der Linie und bleiben immer lesbar (nie auf dem Kopf); ihre Größe folgt der Dicke der Linie auf dem Bildschirm – kleiner beim Herauszoomen, beim Hineinzoomen höchstens die normale Größe, unter 7 px ausgeblendet; View > Signal label size... macht sie größer oder kleiner (30..300 %, Default = 100 %). Eine Linie, die an einem dritten Roboter vorbeiführen oder eine andere fast parallele Linie überdecken würde, wird als flacher waagerechter Bogen vom Hindernis weg gezeichnet; Bezeichnung und Pfeile folgen dem Bogen.
  

  Kollisionskarte einer Fanuc-Zelle: Verriegelungsbereiche entlang der Linien, Linien an einem dritten Roboter vorbei als Bogen; vorne links ein Roboter auf einer Fahrbahn
• Show the program state above the robots – eine Lampe über jedem laufenden Roboter: standardmäßig grün = Fahrt oder Warte auf Folgenstart, orange = Prozesszeit an einem Befehl, rot = Warten. State lamp... stellt die Farben ein (nur bei eingeschalteter Option).
• Free run - ignore all conditions (SPS, interlocks, WARTE BIS, FB, collisions) (Freie Fahrt, Standard: aus) – alle Roboter fahren ihre Programme, ohne auf etwas zu warten: kein SPS-Programm, keine Verriegelungssignale, kein gemeinsamer Start an Warte auf Folgenstart, WARTE BIS und die Fahrbedingungen FB PSPS / FB ONL gehen sofort durch, und die Simulation hält bei Kollisionsgefahr nicht an. Feste Wartezeiten (WARTE ZEIT) und die Bewegungen bleiben. Zum Ansehen der Bewegungen einer Station, deren Ablauf noch nicht bekannt ist – die Zeiten und Kollisionen sind nicht realistisch. Eine Warnung in der Konsole erinnert an die Option. API: sim_options, Schlüssel freeRun; wird in der Simulationsdatei gespeichert (Attribut freeRun von Options).

Vor dem Ablauf. Die Kollisionsprüfung des Ablaufs braucht aktuelle Arbeitsbereiche. Fehlen sie oder sind sie veraltet, fragt der Simulator: Calculate and run (berechnen und starten) oder Run without collision check (ohne Kollisionsprüfung starten); die Befehls-API berechnet sie selbst; seit 2026-10-25 läuft die Berechnung im Hintergrund, das Fenster reagiert und Cancel funktioniert, siehe Arbeitsbereiche. Mit Respect interlock signals fragt eine unvollständige Verriegelungskarte: Show the map (Karte zeigen) oder Run anyway (trotzdem starten).

Während des Ablaufs sind die Optionen der Registerkarte gesperrt. Auch während der Simulation wirken: die Achswerte in der Konsole, die Kollisionskarte, die Statuslampe, Console messages..., Collision risks..., die Geschwindigkeit, Pause und Continue (Quitt).

Kollisionsgefahr im Ablauf Work Zones

Stop the simulation at a collision risk (Standard: ein): fährt ein Roboter ohne Verriegelung in einen mit einem Partner gemeinsamen Bereich, während der Partner in diesem Bereich ist, hält die Simulation sofort an (Pause). Der Simulator macht ein Bild der Szene, schreibt die Achsen aller Roboter und öffnet das Fenster der Kollisionsgefahren. Aus: der Ablauf geht weiter, die Gefahren stehen in der Konsole und im Bericht.

Der Knopf Collision risks... öffnet dieses Fenster, auch während des Ablaufs. Im Fenster: Ignore (der Fall hält die Simulation nicht mehr an), Roboter zu den Punkten, Programme im Editor, Speichern als HTML / PDF. Benachbarte Punkte derselben Stelle sind standardmäßig ein Fall (siehe Plugin-Einstellungen > Kollisionsbericht). Die kleinen Knöpfe der Tabelle (Roboter zu den Punkten, Programm im Editor) behalten ihre Größe, auch in der letzten Spalte. Wo die Gefahr in der Zelle liegt, zeigen die Kollisionsstellen in der Szene.

Roboter zu den Punkten (Robots to the points, nur bei angehaltener oder pausierter Simulation): bei einer Kollisionsgefahr aus den Arbeitsbereichen fahren beide Roboter in die Punkte ihrer Programme. Bei einer Berührung der 3D-Modelle (KOLLISION (3D-Modelle)) fahren beide Roboter in ihre Achsen an der ersten Berührungsstelle der Zeile (die Achsen speichert die Live-3D-Prüfung). Eine Zeile kann mehrere Berührungsstellen enthalten (siehe Kollisionsstellen): jeder weitere Klick auf den Knopf fährt die Roboter zur nächsten Stelle der Zeile, nach der letzten beginnt es wieder mit der ersten. Die Konsole nennt beide Roboter, die Stelle und die Simulationszeit, z. B. Berührung 2 von 6 dieser Zeile (7.34 s); die rote Kugel mit derselben Zeit liegt auf den sich berührenden Teilen. Der Knopf einer 3D-Zeile mit mehr als einer Stelle zeigt die Anzahl der Stellen (z. B. 6), nach einem Klick die gezeigte Stelle (z. B. 2/6).

Bei einer Zeile der Arbeitsbereiche (violett) prüft der Simulator in dieser Stellung der Programmpunkte zusätzlich einmal die 3D-Modelle (dieselben Modelle wie Live 3D: Glieder der Roboter, CAD-Modell des Werkzeugs mit Greifern / Zangen, Vorrichtungen, Dummy-Werkzeug). Berühren sie sich, markiert eine orange Kugel die Stelle (Beschriftung 3D-Kontakt in den Programmpunkten R2 / R1) und die Konsole warnt: im Lauf waren die Roboter nicht gleichzeitig dort, aber ein anderes Timing (Geschwindigkeit, Warten, SPS) macht daraus eine echte Kollision – die Verriegelung halten, bis der Bereich frei ist. Sonst schreibt die Konsole, dass sich die Modelle nicht berühren, mit dem kleinsten Abstand und den Teilen. Die erste Prüfung dauert einige Sekunden (die Modelle werden gelesen), weitere sofort. Die orange Kugel verschwindet beim nächsten Roboter zu den Punkten oder beim Start der Simulation.

Eine blaue Zeile unter der Tabelle sagt, was die 3D-Ansicht nach dem letzten Klick zeigt, z. B. Gezeigt: Berührung 2 von 6 bei 7.30 s - R2 in UP142/P2, R1 in UP142/P2 (die rote Kugel mit dieser Zeit) oder Gezeigt: Programmpunkte - ... mit dem Ergebnis der Prüfung der Stellung. Die Tooltips der Spalten Point / Partner point erklären die Schreibweise: P2-P5 = der Bereich der Punkte P2 bis P5, P2, P12 = die beiden Punkte P2 und P12.

API: {"cmd":"collision_case","key":"...","action":"points"} (ein wiederholter Aufruf = die nächste Berührung), die Antwort enthält point ([x, y, z] mm, die Kugel der gezeigten Berührung), place / places (3D-Zeilen) und shown (der Text der blauen Zeile); bei einer Zeile der Arbeitsbereiche kommt das Ergebnis der Prüfung der Stellung etwa 0,2–6 s später in der Konsole.

Live-3D-Kollisionsprüfung Collision 3D

Die Option Live-3D-Kollisionsprüfung prüft die 3D-Modelle während der Simulation der Station (Run on all robots, Fast Run, Robustheitstest, Lauf über die Befehls-API – nicht der Lauf eines einzelnen Roboters). Bei jeder Prüfung vergleicht der Simulator:

• die Roboter – die Dreiecke ihrer Glieder,
• die Werkzeuge – das Werkzeugmodell am Flansch oder das Dummy-Werkzeug: eine Kugel im TCP und ein Körper (Kapsel) vom Flansch zum TCP. Der Körper wird nur verwendet, wenn der TCP weniger als 1 m vom Flansch entfernt ist.

Die Felder der Prüfung lassen sich nur bei eingeschalteter Live 3D collision check ändern; fester Schritt braucht Prüfung in eigenem Thread, und Schritt braucht fester Schritt.

Kollision und Annäherung. Jede Prüfung misst den kleinsten Abstand der Oberflächenpunkte der beiden Modelle (die Punkte liegen etwa 0,6–0,7 × Zelle auseinander, 18–21 mm bei 30 mm). Das Ergebnis ist eine von zwei Arten:

Warum: eine gemeinsame Zelle von 30 mm mit 10–26 mm Abstand der nächsten Punkte hängt vom Zeitpunkt der Prüfung ab – in einem Test (2026-10-25) wurde dieselbe Vorbeifahrt der Zangen meist als Annäherung, in einzelnen Läufen als Berührung gemeldet, mit jedem Format der Werkzeugmodelle (siehe Formate der Werkzeugmodelle). Echte Kollisionen zeigen 0–3 mm. Wird eine Annäherung derselben zwei Roboter in denselben Punkten im Lauf zum Kontakt, ist der Fall eine Kollision (eine Zeile; die Annäherungen zählen mit).

Ältere Simulationsdateien und Agenten. Eine Simulationsdatei ohne live3dContact verwendet 5 mm; ihr live3dWarn bleibt wie gespeichert (oft 0 = aus – dann sind nur die gemeinsamen Zellen ohne Kontakt Annäherungen). Die Grenzfälle, die vor dem 2026-10-25 als KOLLISION gemeldet wurden, sind jetzt Annäherungen: sie halten die Simulation nicht an und sind in Check interlocks Warnungen. Nahe am alten Verhalten: Kontakt bis 50 mm (dann ist jede Annäherung unter 50 mm eine Kollision, auch ohne gemeinsame Zelle).

Orte der Kollisionen (Kugeln)

Nach einem Lauf mit Live-3D-Kollisionsprüfung und / oder der Prüfung der Arbeitsbereiche zeigt die 3D-Szene an jeder Stelle, an der die Prüfung ein Problem gefunden hat, eine Kugel. Das Menü Ansicht > Kollisionsstellen anzeigen (View > Show the places of collisions) schaltet sie ein und aus (Standard: ein, wird in den Einstellungen gespeichert). Ein Fall der Arbeitsbereiche hat eine Kugel. Ein Fall einer 3D-Berührung behält bis zu 4 Berührungsstellen, die mehr als 400 mm auseinander liegen (z. B. zuerst berühren sich die Zangen, später der Arm den Unterarm); jede Stelle hat ihre eigene rote Kugel, Zeit und Roboterachsen. Die Beschriftung über einer Kugel nennt den Roboter, den Partner und die Simulationszeit dieser Stelle.

Ansicht > Beschriftung der Kollisionsorte anzeigen (View > Show the labels of the collision places; Standard: ein, wird in den Einstellungen gespeichert) schaltet die Texte über den Kugeln; aus = nur die Kugeln, nützlich, wenn viele Beschriftungen die Roboter verdecken. Beide Schalter stehen auch im Kontextmenü der 3D-Ansicht. API: {"cmd":"view","collisionPlaceLabels":false}.

Kollisionsstellen nach einem Lauf zweier Roboter: rote Kugeln = Berührungen der 3D-Modelle, violette Kugeln = Kollisionsgefahren aus den Arbeitsbereichen (Bild mit englischer Oberfläche)

Die Kugeln werden über den Modellen gezeichnet und sind so auch durch einen Roboter oder ein Werkzeug hindurch sichtbar. Fälle, die im Fenster Collision risks auf Ignore gesetzt sind, werden nicht gezeigt. Die Kugeln bleiben nach dem Ende des Laufs stehen und werden beim Start des nächsten Laufs entfernt.

Die Farben werden in Ansicht > Farben der Kollisionsstellen... eingestellt (Restore Defaults setzt Rot, Violett und Gelb zurück). API: {"cmd":"view","collisionPlaces":true}, {"cmd":"view","collisionPlaceColor3D":"#ff0000","collisionPlaceColorZone":"#e000e0","collisionPlaceColorProximity":"#ffc000"} (siehe Befehls-API).

Mehr Kugeln als Zeilen. Das Fenster Collision risk in the simulation fasst die Fälle eines Roboterpaars in aufeinanderfolgenden Punkten zu einer Zeile zusammen (z. B. UP142/P2-P5; die Spalte Count ist die Anzahl der Prüfungen, die ihn gefunden haben; die Spalte Art zeigt 3D-Kollision, 3D-Annäherung oder Arbeitsbereiche, mit dem nächsten Abstand der Modelle in Klammern; eine Zeile der Annäherung ist orange, nicht rot). Die Szene zeigt für jede Stelle jedes Falls eine Kugel, es kann also mehr Kugeln als Zeilen geben – im Bild oben gehören vier rote Kugeln (7.1, 7.4, 7.7 und 7.9 s) zu einer Zeile.

Die Berührungsstellen einer Zeile durchgehen. Roboter zu den Punkten (grüner Play-Knopf) einer 3D-Zeile fährt beide Roboter in ihre Achsen an der ersten Berührungsstelle der Zeile. Jeder weitere Klick fährt sie zur nächsten Stelle aller Fälle der Zeile; die Konsole schreibt z. B. 'R2' und 'R1' bei der Berührung 2 von 6 dieser Zeile (7.34 s) - die rote Kugel mit dieser Zeit markiert die Stelle; erneut klicken für die nächste Berührung. Nach der letzten Stelle beginnt es wieder mit der ersten. Die rote Kugel mit derselben Zeit liegt dann auf den sich berührenden Teilen.

Zeilen der Arbeitsbereiche. Roboter zu den Punkten einer Zeile der Arbeitsbereiche stellt beide Roboter in die Punkte ihrer Programme. Diese Stellung muss im Lauf nie gleichzeitig vorkommen (z. B. beide Roboter in ihren Schweißpunkten, während im Lauf einer schon weg war); dass dort keine rote Kugel ist, ist also richtig: die roten Kugeln markieren nur Berührungen, die im Lauf wirklich vorkamen. Ob sich die Modelle in dieser Stellung berühren würden, zeigt die Prüfung der Stellung: eine orange Kugel und eine Warnung in der Konsole oder der kleinste Abstand (siehe Kollisionsgefahr im Ablauf).

Roboter zu den Punkten, Berührung 1 der Zeile: die rote Kugel 3D contact R2 / R1 7.1 s liegt dort, wo sich die beiden Schweißzangen berühren

API: {"cmd":"collision_case","key":"...","action":"points"} macht dasselbe (ein wiederholter Aufruf = die nächste Stelle; oder der Schlüssel einer einzelnen Berührung) und antwortet mit point [x, y, z] mm der gezeigten Berührung. Die Stelle ansehen: {"cmd":"view","target":[x, y, z],"zoom":6} und scene_shot.

Genauigkeit: wie weit sich ein Roboter zwischen zwei Prüfungen bewegt

Eine Berührung, die kürzer ist als die Zeit zwischen zwei Prüfungen, kann fehlen. Entscheidend ist nicht die Zeit, sondern wie weit sich ein Punkt eines Modells zwischen zwei Prüfungen bewegt, solange der Roboter nahe an einem Partner ist (näher als Abstand bis) – schnelle Bewegungen im freien Raum spielen keine Rolle. Nach jedem Lauf schreibt die Konsole:

• die Anzahl der Prüfungen, den Modus, die Zeit einer Prüfung (Median und 95 %), den Abstand zwischen den Prüfungen,
• die größte Bewegung eines Punkts eines Modells zwischen zwei Prüfungen nahe an einem Partner (Roboter, Zeit) und den 95-%-Wert,
• wie lange die Simulationsuhr auf die Prüfungen gewartet hat,
• eine Empfehlung für diese Station und diesen Rechner: den Schritt, bei dem sich jeder Punkt nahe an einem Partner zwischen zwei Prüfungen höchstens Zelle + Warnung unter (mindestens Zelle + 20 mm) bewegt, und bis zu welcher Simulationsgeschwindigkeit die Uhr nicht auf die Prüfungen wartet.

Dieselben Werte stehen in der API (live_check → stats) und für jeden Lauf eines Robustheitstests in seinem Protokoll und Bericht. Ein Lauf mit Live-3D-Prüfung an einer neuen Station oder einem neuen Rechner genügt, um die Einstellungen zu erhalten.

Gemessen (Station A: 5 Roboter + SPS-Programm, 10 Takte = etwa 720 s Simulation, Zelle 20 mm, Laptop i7-8750H)

• Mit festem Schritt ist das Ergebnis bei 200 % und 400 % gleich – die Geschwindigkeit ändert nur die Dauer.
• Mehrere Kerne: eine Prüfung dauert 17 ms statt 42 ms, die Ergebnisse sind gleich. Seit 25.10.2026 arbeiten die Kerne für den ganzen Lauf in einem festen Satz von Threads (kein Speicherzuwachs während des Laufs, schnellere 3D-Ansicht – siehe Auslastung des Rechners).
• Ein Schritt von 20 ms hält jede Bewegung nahe am Partner unter Zelle + Sicherheitsabstand (70 mm) und findet Annäherungen, die ein Schritt von 50 ms übersieht. Auf diesem Rechner wartet die Uhr dann auf die Prüfungen – ein Lauf mit 400 % läuft effektiv mit etwa 85 %.
• Szene nur alle 1000 ms zeichnen: 6 % kürzer, halbe Last der Grafikkarte.

Verriegelungssignale zwischen den Robotern Simulation

Mit Respect interlock signals (A8n / Makro20 / A4n) tauschen die Roboter bei Run on all robots die Verriegelungssignale des VW-Standards so aus, wie es die SPS tut:

• A(80+n) = EIN in einem Punkt fordert den Bereich n an,
• SPSMAKRO20 = EIN im selben Punkt wartet, bis kein Partnerroboter im Bereich n ist, dann belegt der Roboter den Bereich,
• A(40+n) = EIN (erster Punkt nach dem gemeinsamen Bereich) gibt ihn frei, A(40+n) = AUS belegt ihn ohne Warten.

Der Partnerroboter eines Bereichs kommt aus den Beschreibungen der Signale E(40+n), A(40+n) und A(80+n) in den Langtexten des Roboterarchivs (Longtexts) und aus den Kommentaren Verriegelung n ... 0001R03 in den Programmen; ein Bereich ohne Beschreibung wird mit jedem Roboter geteilt, der denselben Bereich verwendet. Bei Fanuc-Robotern kommen die Beschreibungen aus den Signalkommentaren der Steuerung in DIOCFGSV.IO (DI n = E n, DO n = A n, z. B. DI 41 "L.Ant.1>R1" = Freigabe vom Partnerroboter R1), siehe Fanuc-Roboter. Beim Start zeigt die Konsole die Verriegelungskarte (Bereich - Partner) jedes Roboters.

Während des Ablaufs meldet die Konsole jedes Warten: waited 16.38 s at folge12 P17 for interlock 3, 5 (taken by ...) (Simulationszeit). Am Ende zeigt sie die Wartezeit pro Roboter - die Punkte, an denen Taktzeit verloren geht. Ein Roboter, der sein Programm mit noch belegtem Bereich beendet (kein A(40+n) = EIN), wird als Fehler gemeldet, und wenn alle Roboter aufeinander warten, stoppt der Ablauf mit der Meldung deadlock.

Die Simulation folgt der Programmreihenfolge und dem Bewegungsplaner; sie zeigt, wo Roboter warten, nicht ob die Bereiche geometrisch an der richtigen Stelle freigegeben werden - dafür Work Zones und Check interlocks verwenden.

Programmablauf

Ohne die Stations-SPS werden die Eingänge der Steuerung und die SPS nicht simuliert (außer den Verriegelungssignalen oben, wenn eingeschaltet); die Bedingungen der Programme werden daher wie folgt ausgewertet:

• Stop on breakpoints – der Roboter beendet seinen Durchlauf an einem Haltepunkt in seinem Programmbaum (Rechtsklick auf einen Punkt – Add breakpoint). Jeder Roboter behält seine eigenen Haltepunkte, auch wenn ein anderer Roboter ausgewählt ist; es zählen nur Punkte des Hauptprogramms (Folge), nicht Punkte in den UPs. Sinnvoll für einen Roboter oder für Roboter ohne SPS-Programm, um ein Programm bis zu einem Punkt zu prüfen (Position, Erreichbarkeit, Verriegelungen bis dorthin). Mit dem SPS-Programm ist die Option gesperrt: der Roboter würde seinen Durchlauf beenden und die Station würde in HOME auf ihn warten,
• UP-Aufrufe (UP calls) – Do not execute, Only unconditional calls (= EIN) oder All calls (conditions ignored) (Standard). All calls führt jedes in einem Punkt aufgerufene Unterprogramm aus, die anderen Optionen schränken die Aufrufe ein. Makros SPSMAKRO<n> = EIN (ohne Bedingung) laufen wie UPs aus KRC\R1\Makros\Makro<n>.src; Makros mit Bedingung werden übersprungen (die Startmeldung zählt sie); Makro20 und Makro45 wirken als Verriegelungsbefehle. Ein UP-Aufruf mit Bedingung (z. B. UP101 = F12, Kappenfräsen alle paar Takte): eine Bedingung auf im Programm gesetzten Flags wird berechnet (AUS = das UP wird nicht aufgerufen); eine Bedingung auf Eingängen E oder auf Signalen, die das Programm nicht setzt, hängt von der SPS ab – das UP läuft in jedem Takt und der Taktzeitbericht weist darauf hin. Ein UP-Aufruf in einem Fold mit einem Leerzeichen nach dem Semikolon (; FOLD UP71 = F901) wird ebenfalls ausgeführt (seit 2026-10-20; vorher wurde er ignoriert). Das gilt für jeden als ; FOLD mit Leerzeichen geschriebenen Befehl (ältere Archive, Makros): ist er eine VW-Befehlsform (%CVW_SPS, nicht TECH), wird er wie ;FOLD simuliert; strukturelle Folds bleiben ignoriert,
• Sprünge GOTO Label n = Bedingung (z. B. das Bürsten-UP48: Label 1 am Anfang, F935 = F934, F934 = AUS, am Ende GOTO SPSLabel 2 = F935, F934 = EIN, SPSLabel 2, GOTO Label 1 = F934 – das UP läuft zweimal): die Simulation verfolgt die im Programm gesetzten Flags, Ausgänge und Merker in der Reihenfolge der Ausführung, auch die Sprünge GOTO SPSLabel in einem Punkt, und wiederholt oder überspringt die Punkte (höchstens 20 Durchläufe); ein Flag, das vor jeder Zuweisung gelesen wird, gilt als AUS (Programmstart). Eine Bedingung auf Eingängen E oder auf Signalen, die das Programm nicht setzt, lässt sich ohne SPS nicht berechnen – das Programm läuft einmal und der Taktzeitbericht zeigt eine rote Zeile Programmablauf (GOTO Label): der simulierte Takt enthält eine Wiederholung, die ohne SPS nicht abschätzbar ist. Die Laufdaten (run_data) enthalten dieselben Zeilen in programFlow. REPEAT UP101 N= 999 STOP= !F298 (zyklischer Aufruf) wiederholt das UP, bis die STOP-Bedingung erfüllt ist (aus den Flags des Programms, höchstens 20 Durchläufe); ein durch eine Regel ausgeschlossenes UP wird mit seiner Aufrufbedingung gemeldet (ob die Station es aufrufen würde),
• Call trace – der Taktzeitbericht listet für jeden Roboter die in der Simulation aufgerufenen Programme in der Reihenfolge der Ausführung, z. B. folge81 → UP42 → UP43 → 2× UP48 → (UP101 ausgeschlossen) (2× = REPEAT oder Schleife GOTO Label, in Klammern nicht ausgeführte Aufrufe); eine Zeile, wenn alle Takte gleich waren, sonst jeder Takt. KI-Vorschläge importieren vergleicht die Zeiten vorher / nachher nur bei gleichem Call trace und markiert einen Roboter mit anderem Call trace (Laufdaten: callTrace),
• Program rules – Exclude UP und Exclude MAKRO überspringen die Aufrufe der angegebenen Nummern (eine Nummer oder eine Liste mit Bereichen, z. B. 80, 84-85, 89), Wait at command hält den Roboter die angegebene Zeit an einem Punkt mit dem Befehl an (z. B. SERVOZANGE 1200 ms; die Programmzeiten im Programmbaum enthalten diese Halte), Custom command – dasselbe mit einem regulären Ausdruck für den Befehl (ohne Groß-/Kleinschreibung, sichtbarer Text des Befehls ohne Schrittnummer; Leerzeichen und Tabulatoren im Befehl zählen als ein Leerzeichen, ein Leerzeichen im Ausdruck genügt - kein \s+ nötig, z. B. ^TECH1\.EZ/SP/KE .*P1=10 oder SERVOZANGE|ZANGE AUF); beim Tippen ist der Rahmen des Editors grün bei gültigem Ausdruck und rot bei einem Fehler (Fehler im Tooltip), der Text in der Tabelle grün / rot; eine Regel mit ungültigem Ausdruck wird mit Meldung übersprungen, Exclude FB PSPS – siehe FB PSPS. Prozesszeit von Wait at command / Custom command: PrAct – der Ausgang Prozess aktiv des Roboters (Standard A4039, Plugin-Einstellungen > Simulation) ist während des Prozesses EIN; das SPS-Programm der Station und das SmartPad sehen ihn. Modus – solo: der Roboter steht die ganze Zeit; davor: der Prozess beginnt Überlappung ms bevor der Roboter den Punkt erreicht; dahinter: der Prozess endet Überlappung ms nachdem der Roboter den Punkt verlassen hat (auch wenn er dort wartet, z. B. an WARTE BIS) – der Roboter steht nur die Zeit minus Überlappung (z. B. SERVOZANGE 1200 ms, dahinter 400 ms: Halt 800 ms, PrAct 1200 ms); Nachladen (z. B. Bolzen Nachladen 2 s): die Zeit läuft ab dem Ende des Prozesses im Punkt, während der Roboter weiterfährt – im nächsten Punkt mit demselben Befehl wartet der Roboter nur auf den Rest (Fahrt kürzer als die Nachladezeit). POT-Zeiten importieren... übernimmt die Prozesszeiten des POT-Makros (VW Makro40) in die Regeln – siehe Import der POT-Prozesszeiten,
• Stop at WARTE BIS: (Standard E23) – Bedingungen getrennt mit ;, z. B. E23; E80 & E76 (die Reihenfolge der Signale in & spielt keine Rolle; der Knopf ... bietet die WARTE-BIS-Bedingungen der Programme an). Ein Roboter an WARTE BIS mit einer dieser Bedingungen hält an und wartet auf Continue (Quitt) – wie die Freigabe der Station von der SPS. Mit dem SPS-Programm werden die Bedingungen aus den Signalen der SPS berechnet. once per cycle (einmal pro Zyklus) – die Freigabe gilt bis zum nächsten Folgenstart: ein zweites WARTE BIS mit derselben Bedingung im selben Zyklus geht sofort durch (mit dem SPS-Programm aus),
• Continue (Quitt) – setzt alle an WARTE BIS wartenden Roboter fort. Quitt if all robots wait drückt ihn automatisch, wenn alle laufenden Roboter warten und mindestens einer an WARTE BIS wartet (mit dem SPS-Programm aus),
• Stop at 'WARTE BIS AUS' and wait for Continue (Standard: ein) – der Roboter wartet am Warten auf Zyklusende und fährt mit Continue (Quitt) fort,
• Stop at every 'WARTE BIS' – jedes Warten auf einen Eingang hält den Roboter bis Continue an,
• Ignore motion conditions (FB PSPS / FB ONL) (Fahrbedingungen ignorieren, Standard: aus) – die Roboter warten nicht auf die Fahrbedingungen FB PSPS / FB ONL (vor, während und nach den Bewegungen). Zum Testen der Bewegungen eines Programms, z. B. eines Roboters ohne seine Partner; Verriegelungen und Zeiten sind dann nicht realistisch. Die Konsole meldet die erste übersprungene Bedingung des Durchlaufs (Roboter, Bedingung und Stelle); weitere werden ohne Meldung übersprungen. Einen Roboter ganz ohne Warten fahren: Respect interlock signals ausschalten, die Liste Stop at WARTE BIS leeren, Stop at 'WARTE BIS AUS' and wait for Continue und Stop at every 'WARTE BIS' ausschalten und diese Option einschalten. API: sim_options, Schlüssel ignoreMotionConditions; wird in der Simulationsdatei gespeichert (Attribut ignoreMotionConditions von Options),
• Console messages... (Konsolenmeldungen) – welche Meldungen der Roboter geschrieben werden (Programmdurchläufe, Aufruf eines UP, Halt bei Befehlen, WARTE BIS, Warte auf Folgenstart, Warten auf Verriegelungen, unbekannte Werte, Fahrzeiten, SPS-Programm, Programmtimer, Achswerte jedes Punkts zur Kontrolle der Positionen) und wie oft: Die Meldungen werden gesammelt und alle 200 ms (einstellbar) zusammen geschrieben, höchstens 40 Informationszeilen pro Schreibvorgang; Fehler und Warnungen immer. Nur die wichtigen behält das Warten auf Verriegelungen, unbekannte Werte und das SPS-Programm. Weniger Meldungen ergeben eine flüssigere Simulation mit vielen Robotern; die Einstellungen wirken auch während der Simulation. DEBUG schreibt Diagnosemeldungen (jeder Schritt des Zyklus, angeforderte / belegte / freigegebene Verriegelungsbereiche mit dem belegenden Roboter, Folgenstart, Änderungen der Signale, WARTE BIS auf der SPS, Makros und UPs) in die Protokolldatei von DReS (dres.log) statt in die Konsole – zur Analyse einer Simulation; sie wird dadurch langsamer, für die normale Arbeit ausschalten.

Console messages: was geschrieben wird, wie oft, und die Option DEBUG

Die Optionen gelten für den Ablauf eines einzelnen Programms und für Run on all robots.

Import der POT-Prozesszeiten (Makro40) Simulation

POT = Produktion ohne Teil (Geisterfahrt): der Testbetrieb der Station ohne Bauteile, in dem der Roboter statt des realen Prozesses die Prozesszeiten des POT-Makros wartet – dieselbe Situation wie in der Simulation. Die Schaltfläche POT-Zeiten importieren... unter der Tabelle Program rules übernimmt diese Zeiten in die Simulation. Der Import läuft automatisch – Sie öffnen nur das Fenster und bestätigen die Vorschläge:

POT-Zeiten importieren: Applikationen aus Makro40, Ausdrücke aus dem Tech-User des Archivs (VW User KS26.01.98), Modi

1. Der Simulator liest aus dem Archiv jedes Roboters das POT-Makro (VW: Makro40 POT Prozesszeiten setzen, die Nummer des Makros wird abgefragt, Standard 40) und übernimmt alle Applikationen mit ihren Prozesszeiten, z. B. BZ1 Schweissen 1,0 s, BZ1 Bolzen Nachladen 2,0 s. Unterschiedliche Zeiten in den Robotern – die längste (Details im Tooltip der Zeit).
2. Aus dem Archiv wird die VW-User-Version des Roboters ermittelt (VW_User\vw_usr_s.src, z. B. KS26.01.98_20260419) und aus dieser Version werden die Tech-Gruppen und Untergruppen gelesen (dieselben Definitionen wie im Tech-Befehlseditor, alle Formate des Tech-Users). Die Version wird im Fenster angezeigt; eine Version, die in DReS fehlt, wird gekennzeichnet und die Gruppen der Standardversion werden verwendet.
3. Für jede Applikation wird der Befehl im Programm automatisch als regulärer Ausdruck gebildet: Gruppe und Untergruppe am Anfang des Befehls, die Nummer der Applikation als Steuerung, z. B. BZ1 → ^TECH2\s+BZ(\s|$).*\bSteuerung\s*=\s*Nr1\b, STP → ^TECH2\s+STP(\s|$), KL → ^TECH3\s+KL(\s|$), NZ → ^TECH2\s+NZ\/EP(\s|$). Die Gruppe heißt nicht in jeder VW-User-Version TECHn (ältere Versionen z. B. Tech_, TECH2_) – sie wird aus der Version des Roboters übernommen.
4. Die Spalte In Programmen zeigt, wie viele Befehle in den Programmen der Roboter (Folgen, UPs, Makros) passen – man sieht sofort, welche Applikationen die Station wirklich verwendet (0 = nicht verwendet). Die Zeilen des POT-Makros selbst werden nicht gezählt.
5. Der Modus wird vorbelegt: Nachladen für die Nachlade-Applikationen (... Nachladen), sonst solo. Nachladen: die Zeit läuft, während der Roboter weiterfährt; ist die Fahrt zum nächsten Punkt mit demselben Befehl kürzer, wartet der Roboter dort nur noch auf den Rest. davor für Prozesse vor dem Punkt (VOR Prozess, z. B. MS Zuenden, KL Start/Bereit), dahinter – der Prozess endet, nachdem der Roboter den Punkt verlassen hat. Die Bedeutung der Modi steht unter der Tabelle.
6. Die angehakten Zeilen werden zu Regeln Custom command mit PrAct (Ausgang Prozess aktiv, Standard A4039). Die Vorschläge sind nicht angehakt – prüfen und die Zeilen anhaken. Von Hand eingetragene Regeln für dieselben Befehle (z. B. Wait at command SERVOZANGE 1200 ms) würden die Prozesszeit doppelt zählen – nach dem Import listet das Fenster sie auf und entfernt die angehakten. Die Zuordnung wird gespeichert und beim nächsten Import wieder vorgeschlagen.

Merker, Flags und FB PSPS Simulation

Das Roboterprogramm wird wie auf der Steuerung interpretiert: die Inline-Formulare des VW-Standards (der in den Folds angezeigte Text, nicht der darin erzeugte KRL-Code) und einfacher Expertencode außerhalb der Folds (siehe unten). Die Befehle eines Punktes laufen in der Reihenfolge des Programms: ein WARTE BIS, eine Verriegelung (Makro20) oder ein FB PSPS hält die weiteren Befehle des Punktes an, bis die Bedingung erfüllt ist – z. B. A80 = EIN, WARTE BIS E80 & E76, A80 = AUS: der Handshake-Ausgang A80 bleibt EIN, solange der Roboter wartet, und geht erst nach dem Warten AUS. Befehle nach einem UP-Aufruf laufen nach dem UP.

• Merker M – jedes M32 = E42 & E56 ... in der Folge, einem UP oder einem Makro ist eine Definition: der Wert des Merkers wird ständig aus den Signalen der Definition berechnet, auch über andere Merker (M32 = M30 & E80, M30 = E14 & E24 ...; eine Schleife von Definitionen ergibt einen unbekannten Wert). Es gilt die zuletzt ausgeführte Definition. Die Merker der Initialisierung beim Programmstart werden aus den Makros gelesen, die in KRC\R1\VW_User\vw_usr_r.src gestartet werden (Fold Merker und Timer Initialisierung: SELECT(#MAKRO,50 ...), meist Makro50 und Makro57); Makros ohne Punkte und Makros mit Bedingung (SPSMAKRO7 = F277) werden auch gelesen – ihre Zuweisungen laufen, wenn die Bedingung EIN ist,
• Flags F und Ausgänge A – der Wert wird beim Ausführen der Zeile übernommen (F12 = E3 & M4); das SmartPad zeigt die letzte Zuweisung,
• WARTE BIS mit Merkern, Flags oder Timern wird aus der Simulation berechnet (mit dem SPS-Programm immer, ohne es, wenn die Bedingung nach dem Auflösen der Merker keine Eingänge E hat); ein in der Simulation unbekannter Wert (z. B. ein Flag, das nichts setzt) lässt den Roboter weiterfahren. Die Konsole zeigt die Bedingung, in Klammern dieselbe mit aufgelösten Merkern, und was fehlt, z. B. WARTE BIS E42 & M32 (E42 & (E56 & E44)) - wartet, es fehlt: E56 EIN; (?) kennzeichnet ein Signal ohne Wert,
• FB PSPS (Fahrbedingung, "online") wird immer geprüft: das letzte FB PSPS eines Punktes ist die Bedingung der nächsten Bewegungen – vor der Bewegung zum nächsten Punkt wartet der Roboter, bis sie erfüllt ist; ein FB PSPS als erster Befehl eines Punktes wird sofort geprüft und die weiteren Befehle des Punktes warten. Die Regel Exclude FB PSPS in Program rules schaltet es ab. Die Sonderkennung __EVERY__ (bei leerem Wert automatisch eingetragen) ignoriert alle FB PSPS; jeder andere Wert ist eine Bedingung, und ignoriert werden nur die FB PSPS mit derselben logischen Bedingung – die Reihenfolge der Signale, der Operanden von & / + und die Klammern spielen keine Rolle (E24 & M95 & E14 ignoriert FB PSPS = E14 & E24 & M95, aber nicht E14 & M95); der Wert darf zusammen mit FB PSPS = kopiert werden. Der Tooltip der Regel und ihres Wertes beschreibt das ebenfalls,
• FB ONL = Bedingung (alter TPVW-Standard, erster Unterfold eines Punkt-Folds, geschrieben ;FOLD FB ONL = ... oder ; FOLD FB ONL = ...) ist eine Fahrbedingung genau wie FB PSPS (vorher wurde es nicht erkannt): der Roboter wartet vor der Bewegung, bis sie erfüllt ist, sie wird während der Bewegung geprüft, und die Regeln Exclude FB PSPS gelten auch für FB ONL. Die Zusammenfassung in der Konsole nach dem Laden lautet n point(s) with FB PSPS / FB ONL (motion condition),
• FB PSPS während der Bewegung – wie auf dem Roboter wird die Fahrbedingung auch während der Bewegung geprüft, jeweils im Abstand FB PSPS während der Bewegung prüfen der Simulationszeit (Plugin-Einstellungen > Simulation, Standard 100 ms; nur vor der Bewegung = 0). Ist sie nicht mehr erfüllt (z. B. ein Eingang wurde im SmartPad oder von der SPS auf AUS geschaltet), bleibt der Roboter dort auf der Bahn stehen, wo er ist – die Konsole zeigt FB PSPS ... (während der Fahrt zu UP42/P25 - hält auf der Bahn) - es fehlt: E76 EIN – und fährt von dort weiter, sobald die Bedingung wieder erfüllt ist. Der Halt zählt als Warten (Gantt-Diagramm), nicht als Bewegungszeit. Der Bremsweg wird nicht simuliert: der Roboter hält sofort an (innerhalb eines Animationsschritts, 16 ms), der reale Roboter bremst auf der Bahn. Ein kleineres Intervall ist näher am Roboter (12-ms-Takt) und benötigt etwas mehr Prozessorzeit. Auf einer Prozessbahn (LIN, CIRC, KLIN, KCIR, KPTP, SLIN, SCIR, Spline – Bürsten, Laser, Kleben, MAG) ist ein solcher Halt bei VW nicht zulässig: mit der Option Kein Halt auf der Prozessbahn (Einstellungen des Plugins > Simulation, standardmäßig ein) zeigt die Konsole einen Fehler R1: Halt auf der Prozessbahn bei UP48/P17 (KLIN) - 2.4 s auf der Bahn angehalten (auch für ein Warten vor einer Bahnbewegung, die auf eine Bahnbewegung folgt), einmal je Punkt in einem Programmdurchlauf – siehe Kein Halt auf der Prozessbahn,
• Expertencode außerhalb der Folds der Inline-Formulare wird ebenfalls gelesen: $OUT[n] = ... (Ausgang An), $FLAG[n] = ... (Flag Fn), $CYCFLAG[n] = ... (Merker Mn, eine Definition) und WAIT FOR ... (wie WARTE BIS) mit Bedingungen aus $IN, $OUT, $FLAG, $CYCFLAG, $TIMER_FLAG, TRUE / FALSE, NOT, AND, OR und Klammern – z. B. WAIT FOR $IN[23] AND NOT $FLAG[5] = WARTE BIS E23 & !F5. Die Zeile gehört zum Punkt davor und läuft in der Reihenfolge des Programms. Anderes KRL (Bewegungen, IF, Schleifen, Variablen, Vergleiche) wird nicht ausgeführt; lokale Unterprogramme nach dem END des Programms werden ignoriert,
• WARTE ( EIN ) ZEIT n [1/10Sek] (auch WARTE ZEIT = n) – der Roboter hält in diesem Punkt für n geteilt durch die Einheit an ([1/10Sek]: n/10 s, [1/100Sek]: n/100 s, ohne Einheit: n s) und führt danach die nächsten Befehle des Punkts aus. Die Zeit läuft nach der Simulationsuhr: sie wird mit der Simulationsgeschwindigkeit skaliert und steht, solange die Simulation pausiert ist. Der Zustand des Roboters ist Prozesszeit an einem Befehl; mit der Konsolenoption Stops at commands zeigt die Konsole R1: P25 WARTE ( EIN ) ZEIT 15 [1/10Sek] - waits 1.5 s. Eine per GOTO übersprungene Zeile wartet nicht. Ein WARTE ZEIT vor dem ersten Punkt eines UP oder Makros wird ebenfalls simuliert (seit 2026-10-21). Während der Roboter wartet, zeigt der SmartPad die Wartezeit; das Gantt-Diagramm zeigt WARTE ZEIT in einer eigenen Farbe, die Schritte des Zyklus im Bericht haben die Spalte WARTE ZEIT [s] und run_data gibt robots[].zeitPerCycle (WARTE ZEIT je Zyklus in s).
  WARTE ( Bedingung ) ZEIT n (z. B. WARTE ( E12 & !M5 ) ZEIT 50 [1/10Sek]): der Roboter wartet, solange die Bedingung wahr ist, höchstens n geteilt durch die Einheit – die Konsole zeigt R1: P25 WARTE ( E12 ) ZEIT 50 [1/10Sek] - waits while E12, at most 5 s. Ist die Bedingung zu Beginn falsch, wird nicht gewartet (Konsole condition ... is false, no wait); ohne das SPS-Programm ist eine Bedingung mit Signalen der Station unbekannt und der Roboter wartet nicht (Konsole not known in the simulation (no SPS), no wait). WARTE ( EIN ) ZEIT wartet die volle Zeit, WARTE ( AUS ) ZEIT ist nie aktiv, WARTE ( !Bedingung ) ZEIT ist die negierte Bedingung.
  Eine feste Wartezeit ist auf einer Produktionslinie unüblich, daher ist jedes aktive WARTE ZEIT eine Warnung: in der Konsole beim Start der Simulation (Roboter, Programm, Punkt, Zeit) und im Bericht, Abschnitt 3. Was zu prüfen ist (alle Verwendungen mit ihren Zeiten; mit Bedingung wait time up to n s while ... is true). Die Befehls-API listet sie mit wait_times auf (auch während des Laufs),
• ein Roboter, der auf ein Flag, einen Merker oder ein Signal der SPS wartet (WARTE BIS, Bedingungen FB PSPS / FB ONL), zählt bei Quitt if all robots wait (Auto Quitt) als wartend.

Merker aus Signalen, die die Simulation nicht hat (Luft, Wasser, Strom der Zange, Sensoren des Werkzeugs – z. B. M95 Sicherheiten EZ1/SP1), erhalten einen festen Wert in der Signaldatei oder mit Force always EIN im SmartPad.

Bewegungsplaner Simulation

Mit Real motion (motion planner) bewegen sich die Roboter wie in der Steuerung: PTP achssynchron, LIN und CIRC entlang der Bahn, mit Beschleunigung und Überschleifen der Ecken. Real time (1:1) setzt die Animationsgeschwindigkeit auf 100 %. Die Parameter passen die Schätzung an: Programm-Override, PTP-Beschleunigungszeit, Bahnbeschleunigung (from robot archive = DEF_ACC_CP aus $config.dat), Orientierungsgeschwindigkeit und Überschleifen. Default values stellt die Standardwerte wieder her. Draw the real path zeichnet die geplante Bahn statt gerader Linien zwischen den Punkten. Suchlauf (LIN SUCHEN): der Roboter fährt mit VB aus dem Suchlauf-Fold und den letzten Teil vor dem Punkt mit der reduzierten Geschwindigkeit Vred – der längste Fall, das Bauteil im Endpunkt des Suchlaufs (Plugin-Einstellungen > Simulation: Suchlauf: Strecke mit Vred, Standard 120 mm). Ein Suchlauf, der länger als Suchlauf: längste Zeit dauert (Standard 12 s, VW GANTT), gibt eine Warnung in der Konsole, z. B. Suchlauf (LIN SUCHEN) zu P5 dauert 3.63 s. Machine data of the selected robot schreibt die aus den Maschinendaten gelesenen Achsgeschwindigkeiten in die Konsole.

DReS Robot Cell Simulator - Cycle Times: Motion Times of All Robots, CSV Export (YouTube, Englisch)
DReS Robot Cell Simulator - Taktzeiten: Fahrzeiten aller Roboter, CSV-Export (YouTube, Deutsch)

Bewegungszeiten Simulation

Die Tabelle Motion times sammelt je Roboter die geplante Zeit, den Fortschritt, die Anzahl der Punkte, den Status und die Startzeit jedes Programmablaufs; klicken Sie auf eine Spaltenüberschrift, um zu sortieren. Export... speichert eine CSV-Datei (lässt sich in Excel öffnen) mit der Tabelle und der Zeit jedes Punktes (Programm, Punkt, Schritt wie UP81/P3, Bewegungsart, Zeit seit dem vorherigen Punkt und seit dem Start). Clear leert die Tabelle.

Wie realistisch die Simulation ist (Simulationsuhr, Robotersteuerung, woher die Abweichungen kommen, Vergleich von Varianten) – siehe Ablauf, Prozessor und Genauigkeit.

Taktzeitbericht und seine Hinweise Simulation

Times: Stationseffizienz, der längste Takt und die Zeiten jedes Roboters

Nach Run on all robots speichert die Schaltfläche Report... der Registerkarte Times einen lesbaren Bericht (öffnet sich im Browser oder im PDF-Viewer, wenn Gespeicherten Bericht (HTML, PDF) im Standardprogramm öffnen eingeschaltet ist): welcher Roboter den Stationstakt bestimmt, wer wie lange auf welchen Verriegelungsbereich wartet und welcher Partner den Bereich zwischen welchen Punkten hält. Abschnitt 3. Was zu prüfen ist enthält Hinweise für den Programmierer, z. B. Punkte mit Prozesszeit auf einen Roboter mit Reserve verlagern oder Bereich n (A(40+n) = EIN) direkt nach dem gemeinsamen Bereich freigeben. Report - options Vor dem Speichern fragt das Fenster Report - options, was der Bericht enthält: Bild der Station (3D-Ansicht) am Anfang, Gantt-Diagramm eines Zyklus – jeder Roboter mit den mittleren Zeiten seiner Punkte: Bewegung, Prozess (Halt bei einem Befehl), Warten auf einen Verriegelungsbereich, WARTE BIS, WARTE ( EIN ) ZEIT (eigene Farbe, seit 2026-10-21) und Warte auf Folgenstart; die rote gestrichelte Linie ist der längste Roboter. Ein zweites Diagramm kann die Zyklen von .. bis mitteln (z. B. ab Zyklus 2, ohne den Start der Station), PrAct (Prozess aktiv) im GANTT-Diagramm – Option: eine grüne Linie unter dem Roboter, solange der Ausgang Prozess aktiv EIN ist (Regeln mit PrAct), auch der Teil während der Bewegung (davor / dahinter), Save as: HTML (Tooltips in den Diagrammen), PDF (A4 quer, Seitenzahlen, die Diagramme als Bilder, eine Abschnittsüberschrift bleibt nie allein unten auf einer Seite) und / oder Excel – ein Blatt je Tabelle: Zusammenfassung, Roboter, Zyklen (jeder Zyklus jedes Roboters), Warten Verriegelungen, Erster Zyklus, Belegung der Bereiche, Schritte des Zyklus (mittlere Zeit jedes Punkts: Bewegung, Prozess, Verriegelung, WARTE BIS, WARTE ZEIT [s], Folgenstart) und Vergleich; Zahlen sind Zahlenzellen. Alle Dateien erhalten denselben Namen, Compare with a previous run – jeder Bericht speichert die Daten des Laufs daneben (*.rcsrun.json). Die Datei eines früheren Laufs auswählen (z. B. vor einer Änderung der Programme): der Bericht erhält den Abschnitt Vergleich mit dem früheren Lauf – Takt der Station, Effizienz, je Roboter Takt, Warten, Bewegung, Halte und Programmtimer sowie das Warten auf jeden Verriegelungsbereich, mit der Differenz (grün = besser, rot = schlechter). Der Bericht listet auch das Warten auf Verriegelungen im ersten Zyklus (wer den Bereich hält und seit welchem Punkt) und warnt, wenn die Simulationsgeschwindigkeit nicht 100 % war oder während des Laufs geändert wurde – nur bei 100 % ohne Änderungen liefert der Bewegungsplaner Zeiten nahe am realen Roboter. Die Tabelle Roboter (auch das Blatt Roboter der Excel-Datei) hat die Spalte Werkzeug (3D): der Körper am Flansch für die Arbeitsbereiche und die 3D-Kollisionsprüfung – CAD-Modell des Werkzeugs: Name (JT-Modell des realen Werkzeugs), Dummy-Werkzeug (Näherung) (Kugel / Quader) oder kein Werkzeug; zusätzliche Elemente am Flansch (z. B. Werkzeugwechsler) folgen mit +. Der Abschnitt 5. Annahmen der Simulation erinnert daran, dass mit einem Dummy-Werkzeug die Arbeitsbereiche und die 3D-Kollisionsprüfung eine Näherung des realen Werkzeugs sind. Der API-Befehl robot liefert dasselbe als toolKind (cad / dummy / none) und toolText. Die Abschnitte zu den Wettläufen und zur Interlock priority des Laufs sind unter Wettläufe der Anforderungen beschrieben.

Die Texte der Hinweise und ihre Grenzwerte stehen in einer XML-Datei und lassen sich so für einen anderen Standard oder eine andere Sprache ändern, ohne neue Version der Erweiterung. Die Datei wird in der Zeile Berichtshinweise der Registerkarte Zeiten eingestellt:

Die Datei wird bei jedem Bericht gelesen – Datei im Editor speichern und erneut Bericht... klicken, ein Neustart von DReS ist nicht nötig. Abschnitt 5 des Berichts nennt die verwendete Datei. Tipp: die Datei der Installation vor Änderungen in einen eigenen Ordner kopieren – ein Update von DReS überschreibt sie.

Wettläufe der Anforderungen Simulation

Zwei Roboter, die denselben Verriegelungsbereich innerhalb des Zeitfensters (Plugin-Einstellungen > Simulation, Standard 1 s) anfordern, sind ein Wettlauf (request race). In der Simulation gewinnt immer der Roboter, der wenige Millisekunden früher anfordert; an der Linie ist die Reihenfolge zufällig, weil die Roboter nie genau wie in der Simulation fahren. Dann kann der andere Roboter den Bereich zuerst bekommen – die Station fährt eine andere Reihenfolge, die Taktzeit ändert sich, und eine Bewegung ohne Verriegelung kann den Partner an einer Stelle treffen, die die Simulation nie gezeigt hat.

Am Ende einer Stationssimulation schreibt die Konsole für jeden Wettlauf eine Warnung: Bereich, beide Roboter mit den Punkten, kleinster Zeitabstand, wie oft es vorkam und welcher Roboter gewann. Dieselben Wettläufe stehen im Zeitenbericht (Times > Report), in Check interlocks (Code RACE), in den Laufdaten (requestRaces) und in jedem Schritt des Robustheitstests. Mit Fenster mit den Wettläufen ... in den Einstellungen listet ein Fenster sie am Ende auf.

Die Simulation ändert das SPS-Programm nie von selbst. Die Konsole sagt es zusammen mit den Wettläufen: n request race(s): the SPS program is not changed - at the end of the simulation you can add protection blocks ('Interlock priority') or simulate both orders (API race_study). Was Sie am Ende tun können, steht unter Wettläufe: Vorschlag und Simulation beider Reihenfolgen.

Mit Reihenfolge der Roboter bei einem Wettlauf während des Laufs beibehalten (Standard: ein) hält die Simulation die gefundene Reihenfolge in jedem nächsten Zyklus desselben Laufs, solange beide Anforderungen innerhalb des Fensters kommen. Ein Roboter, der später als das Fenster kommt (langsamer, gestört), lässt den anderen fahren – die Reihenfolge ändert sich wie an der Linie, und die Konsole meldet es. Das ist nur eine Regel des Laufs: das SPS-Programm wird nicht geändert. Im Robustheitstest behält ein in einem Schritt gefundener Wettlauf seine Reihenfolge für alle nächsten Schritte des Tests.

Fenster am Ende einer Simulation mit Wettläufen (Wettlauf gefunden) – siehe Wettläufe: Vorschlag und Simulation beider Reihenfolgen

Der Zeitenbericht (Times > Report) hat den Abschnitt Anforderungen im selben Moment (Wettläufe) mit Fenster, beiden Punkten, Gewinner und kleinstem / größtem Abstand, und den Abschnitt Interlock priority in diesem Lauf mit allen Regeln des Laufs (Quelle SPS, Plan, API, test oder auto mit dem Wettlauf, aus dem sie stammt; test und auto sind nur Regeln des Laufs, keine Bausteine im SPS-Programm) und jeder Anwendung einer Regel – eine Reihenfolgeänderung, weil ein Roboter später als das Fenster kam, ist rot.

Zeitenbericht: Anforderungen im selben Moment (Wettläufe) – Bereich 1, 0001R05 gewinnt mit 0,490 s Vorsprung, 0001R03 wartet 8,4 s – und Interlock priority in diesem Lauf mit dem SPS-Baustein (Fenster 1,0 s)

Was tun bei einem Wettlauf:

• Variante B – die andere Reihenfolge simulieren: am einfachsten mit Beide Reihenfolgen simulieren im Fenster am Ende (siehe unten, API race_study). Von Hand: SPS-Baustein Interlock priority mit dem anderen Roboter zuerst, oder raceOrder in einem Schritt des Robustheitstests, oder der API-Befehl race_rules. Gibt Variante B eine andere Taktzeit oder eine Kollision, ist der Wettlauf wichtig. Für Variante B die Regel Order in every cycle ("mode": "order") verwenden: der andere Roboter ist dann immer zuerst, auch wenn er verspätet ist, weil er auf andere Bereiche wartet. Bei Priority within a time window wartet der zweite Roboter höchstens das Fenster ab seiner eigenen Anforderung (seit 2026-10-17) – kommt der erste später, ändert sich die Reihenfolge wie an der Linie; diese Regel hält die Reihenfolge nur bei fast gleichzeitigen Anforderungen.
• Die Reihenfolge in der Zelle festlegen – entweder den Bereich bei dem Roboter, der ihn zuerst bekommen soll, einen Genauhaltpunkt früher anfordern (die Roboter fahren zusammen mit 100 %), oder die SPS gibt den Bereich in fester Reihenfolge (Vorrang im Kollisionsmanagement der SPS) – mit demselben Baustein simulieren.
• Ein größeres Fenster findet mehr Wettläufe (auch solche aus kleinen Geschwindigkeitsunterschieden); 0,5 s findet nur die sehr knappen.

Wettläufe: Vorschlag und Simulation beider Reihenfolgen Simulation

Ein Wettlauf (request race): zwei Roboter fordern denselben Verriegelungsbereich fast im selben Moment an – innerhalb von Wettlauf um einen Bereich - Zeitfenster (Plugin-Einstellungen > Simulation). An der Linie ist die Reihenfolge der beiden Roboter zufällig. Die Simulation findet die Wettläufe, aber sie ändert das SPS-Programm nie von selbst. Sie entscheiden am Ende, was zu tun ist.

Fenster am Ende (Titel Wettlauf gefunden): endet eine Stationssimulation oder ein Robustheitstest mit Wettläufen, kommt dieses Fenster statt Simulation beendet. Es zeigt den Text zum Ende (Zyklen, Zeit) und eine Tabelle der Wettläufe:

Fenster Wettlauf gefunden am Ende einer Stationssimulation: drei Wettläufe (Bereiche 4, 1 und 5), der Roboter, der den Bereich in der Simulation zuerst bekam, der wartende Roboter und der kleinste Zeitabstand; darunter der Vorschlag, Takte pro Lauf und die Schaltflächen Beide Reihenfolgen simulieren, Schutzbausteine hinzufügen und Schließen. Das SPS-Programm wird nicht geändert.

Unter der Tabelle: das Feld Takte pro Lauf: (1..20, Standard 3) und die Schaltflächen:

• Beide Reihenfolgen simulieren – für jeden Wettlauf fährt RCS die Station zweimal: A = Reihenfolge der Simulation, B = die beiden Roboter getauscht (die anderen Wettläufe behalten die Reihenfolge der Simulation). Für jeden Lauf setzt RCS die Bausteine Interlock priority der Variante in das SPS-Programm (der untersuchte Wettlauf im Modus Order in every cycle, die anderen mit dem Zeitfenster), fährt die Station mit der angegebenen Zahl der Zyklen und stellt das SPS-Programm danach wieder her. Verwendet wird der Ablauf des Robustheitstests: Fortschritt und Protokoll stehen auf der Registerkarte Robustness test, der Bericht wird in Dokumente\RCS_Robustheitstest\race_study geschrieben. Nötig sind das Lizenzmodul Simulation (nicht Robustness) und ein aktives SPS-Programm.
• Schutzbausteine hinzufügen – fügt Bausteine Interlock priority mit der Reihenfolge dieser Simulation und einem Kommentar zum Wettlauf in das SPS-Programm ein. Beim Speichern der Simulation kommt die Frage, ob sie behalten oder entfernt werden (siehe Simulationsdatei).
• Schließen – es wird nichts geändert.

Fenster nach der Simulation beider Reihenfolgen (Titel Simulation beider Reihenfolgen - Ergebnis): das SPS-Programm ist wie vorher. Die Tabelle hat eine Zeile pro Wettlauf:

Gewählte Bausteine hinzufügen setzt die gewählten Bausteine Interlock priority in das SPS-Programm, jeden mit einem Kommentar mit den Ergebnissen beider Varianten; ein älterer Baustein desselben Roboterpaars im Bereich wird ersetzt. Schließen (SPS-Programm unverändert) schließt das Fenster ohne Änderung. Konsole und Protokoll schreiben eine Zeile pro Wettlauf, z. B. Simulation of both orders: zone 1: A 0001R05 first - ...; B 0001R03 first - ...; recommended A.

Fenster Simulation beider Reihenfolgen - Ergebnis: für Bereich 4 ergibt Variante A (0001R02 zuerst) einen Stationstakt von 72,1 s und 104,6 s Warten, Variante B (0001R05 zuerst) 82,4 s und 196,1 s, beide mit 4 Kollisionsgefahren – A ist unter Behalten vorgewählt. Gewählte Bausteine hinzufügen setzt die gewählte Reihenfolge in das SPS-Programm, Schließen (SPS-Programm unverändert) ändert nichts. Die Zeile über der Tabelle nennt den Pfad des Berichts.

API: Befehl race_study (Aktionen status, add_blocks, start, stop, apply).

Simulationsdatei

Simulation → Save simulation... / Load simulation... speichern und laden die Optionen der Registerkarte Simulation zusammen mit der Zelle (siehe auch Speichern und laden). Seit 2026-10-16 enthält die Datei auch Stop the simulation at a collision risk und alle Felder der Live 3D collision check (Element Options: stopAtCollisionRisk, live3d, live3dCell, live3dCapsule, live3dRange, live3dWarn, seit 2026-10-25 live3dContact – eine Datei ohne dieses Attribut verwendet 5 mm). Die Bedingungen der manuellen Synchronisation (WARTE BIS, z. B. E80 & E76) stehen im Element SyncWaits; eine Datei ohne dieses Element lässt das Feld unverändert (es wird nicht geleert). Der API-Befehl sps_program mit file liest auch das SPS-Programm (Element Sps) aus einer solchen Datei.

Für einen Fanuc-Roboter behält das Element ArchiveRobot den Pfad des Fanuc-Archivs, nicht des übersetzten Archivs im Cache; die Übersetzung wird bei jedem Laden neu erstellt.

Archiv aus einer ZIP-Datei (seit 2026-10-21): wurde das Archiv eines Roboters aus einer ZIP-Datei entpackt, behalten die Simulationsdatei und die Sitzung auch die ZIP-Datei; fehlt der entpackte Ordner im Cache (Cache gelöscht), wird die ZIP-Datei beim Laden erneut entpackt. Roboter einer Process-Simulate-Studie finden ihren Archivordner oder ihre ZIP-Datei mit dem Roboternamen neben der Studie (Archivsymbol mit Tooltip im Baum, siehe Insert robots at study positions). Der API-Befehl robot gibt archive und archiveZip zurück.

Zuletzt geladene Simulationen (seit 2026-10-18): Simulation → Zuletzt geladene Simulationen (Recent simulations) zeigt die letzten 15 geladenen Simulationsdateien (auch die über die API geladenen), die neueste zuerst; nur Dateien, die noch existieren. Ein Klick lädt die Simulation wie Load simulation..., ohne Dateidialog. Während der Simulation oder bei leerer Liste ist das Menü gesperrt. API-Befehl recent_files (lesend, ohne Lizenz): Antwort {"ok":true,"simulations":[...],"studies":[...],"current":"<Simulation_File>"} – simulations = diese Liste, studies = die zuletzt geöffneten Studien / Zellen (File → Recent files), current = die jetzt geladene Simulationsdatei. Der KI-Agent findet eine vom Benutzer genannte Datei in dieser Liste.

Werkzeugmodell aus einer JT-, glTF-, STL- oder STEP-Datei (seit 2026-10-22, glTF / STL / STEP seit 2026-10-25): ein mit dem Robotermenü Werkzeugmodell (JT / STEP / STL / glTF)... oder der API tool_model angebautes Werkzeugmodell wird im Element Docked gespeichert (Attribute robot, tool, position und jtFile = Pfad der Modelldatei – das Attribut behält seinen Namen auch für .gltf, .glb, .stl, .stp und .step, ältere Simulationsdateien bleiben gültig); die Sitzung speichert es in attached[].file. Beim Laden wird die Modelldatei erneut eingefügt und das Modell mit der gespeicherten Lage am Flansch angebaut (ein Dummy-Werkzeug des Roboters wird entfernt). Relative Pfade werden vom Ordner der Simulationsdatei aus aufgelöst, sodass ein verschobenes Simulationspaket seine Werkzeugmodelle findet; ein Modell, das nicht angebaut werden kann, wird mit dem Grund im Meldungsfenster aufgeführt.

Formate der Werkzeugmodelle in der Live-3D-Prüfung. Werkzeugmodelle, die aus dem JT™-Datenformat in glTF oder STL konvertiert wurden, liefern in der Live-3D-Kollisionsprüfung vergleichbare Ergebnisse. Die Konvertierung hat keinen Einfluss auf die Genauigkeit der Berechnung: das konvertierte Modell hat dieselben Dreiecke wie die detaillierteste Stufe des JT™-Modells, und die Kollisionsprüfung und die Arbeitsbereiche verwenden genau diese Dreiecke. Test: zwei Schweißzangen (R1, R2) in einer Station, originale JT™-Modelle, glTF und STL, 100 / 200 / 400 % Geschwindigkeit: in jedem Lauf und mit jedem Format wurden dieselben drei Berührungen (1–4 mm) gefunden. Ein Grenzfall bei 20–30 mm wurde als Annäherung gemeldet, in einzelnen Läufen als Berührung – das hängt vom Zeitpunkt der Prüfung ab, nicht vom Format; für solche Stellen einen festen Prüfschritt von 10 ms verwenden. Arbeitsbereiche aus Dreiecken: JT™ 14 s, glTF 9 s, STL 7 s.

Bausteine Interlock priority aus Wettläufen: wird das SPS-Programm mit der Simulation gespeichert und wurden für Wettläufe auf Ihre Wahl Bausteine Interlock priority eingefügt (Schaltfläche Schutzbausteine hinzufügen oder Gewählte Bausteine hinzufügen, oder API race_study), die noch nicht bestätigt sind, fragt Save simulation danach und listet die Bausteine auf:

• Save with the blocks (mit den Bausteinen speichern) – das SPS-Programm wird mit ihnen gespeichert,
• Save without the blocks (ohne die Bausteine speichern) – die Bausteine werden aus dem SPS-Programm entfernt (auch aus dem SPS-Editor und den Einstellungen), dann wird die Datei ohne sie gespeichert,
• Cancel – es wird nichts gespeichert.

Nach der Antwort kommt die Frage für diese Bausteine nicht wieder. Ohne SPS-Programm in der Datei gibt es keine Frage. API-Befehl save: "raceBlocks": "keep" (Standard) oder "remove", ohne Frage; die Antwort enthält raceBlocks (none = keine solchen Bausteine, kept, removed) und raceBlocksCount. race_rules und race_study liefern pendingBlocks – die Bausteine, die noch auf diese Entscheidung warten.

JT-Modelle als glTF (automatische Umwandlung)

Seit 2026-10-25 wandelt der Simulator die benötigten Modelle im JT™-Datenformat selbst um und lädt statt der JT-Datei das umgewandelte glTF-2.0-Modell (.glb, Teile und Farben) – an derselben Stelle, mit derselben Montage am Flansch und denselben Versätzen aus der Studie (das glTF-Modell behält das Koordinatensystem des JT-Modells; Test 2026-10-25: Montage Z 38 mm am Flansch für JT und glTF identisch). Die Umwandlung macht das eigenständige Programm modelconv (eine Schweißzange mit 0,5–0,8 Mio. Dreiecken in etwa 1 s).

• Welche Modelle: die an den Robotern einer Studie montierten Werkzeuge und Vorrichtungen (File → Insert robots at study positions, vollständiges Öffnen einer Studie – in Available objects gewählte Komponenten), die Werkzeugmodelle einer Simulationsdatei (Docked) und einer Sitzung sowie eine in Tool model... / API tool_model gewählte JT-Datei. In der Variante mit dem JT-Leser bleiben Roboter einer Studie (Glieder k1..k9) und Komponenten mit Mechanismus (Robcad-Datei .m neben der JT-Datei, z. B. Linearachse) JT. Eine ganze mit File → Insert eingefügte JT-Datei wird als JT geladen.
• Variante ohne JT-Leser (Qt3D-Ansicht, seit 2026-10-25): die Roboter einer Process-Simulate-Studie und die Komponenten mit Robcad-Mechanismus .m (Greifer, Vorrichtungen mit beweglichen Teilen / Spannern, Kappenfräser, Werkzeugwechsler, Drehtische, Linearachsen, Menschmodelle) werden ebenfalls nach glTF umgewandelt und mit dem Knotenbaum des JT-Modells geladen (Namen der Glieder k1..k9 und der Mechanismusglieder wie im JT-Modellbaum). Der Roboter hat seine Achsen und bewegt sich wie in der Variante mit dem JT-Leser, die Werkzeuge sitzen am Flansch, eine Linearachse erhält ihre Länge aus E1. Vorher wurden diese Komponenten in dieser Variante nicht geladen (no converted glTF model ... the component is not loaded). Das Fenster Available objects (Bereich JT-Modelle als glTF) und die API model_cache zählen in dieser Variante alle benötigten JT-Dateien (auch Roboter und Mechanismen). Seit 2026-10-25 aktualisiert ein Bild der Simulation nur die bewegten Teile; die Textur der Texte in der Ansicht (Beschriftungen der Roboter) wird nur nach einer Änderung der Kamera oder der Texte neu gemalt; das Schließen einer großen Szene oder Neue Szene gibt die 3D-Teile jeder Komponente auf einmal frei (Baum und Ansicht werden zusammen geleert). Die Konsole zeigt einmal die Grafikkarte der 3D-Ansicht (3D view: graphics card <Renderer> / <Hersteller> / OpenGL <Version>, in beiden Varianten; API status.glRenderer).
• Wo: <Name der JT-Datei>.glb und <Name>.glb.json neben der JT-Datei (Standard) oder in einem gemeinsamen Ordner (%LOCALAPPDATA%\DrAmaT\RCS\Models, Dateiname mit kurzem Schlüssel des JT-Ordners). Ohne Schreibrecht neben der JT-Datei wird automatisch der gemeinsame Ordner verwendet, das Meldungsfenster sagt es.
• Wiederverwendet, solange die .glb existiert, nicht älter als die JT-Datei ist und ihre .glb.json Größe und Datum der JT-Datei enthält – eine geänderte JT-Datei wird neu umgewandelt.
• Modi (Plugin-Einstellungen > Simulation): Auto (Standard) wandelt fehlende Modelle ohne Rückfrage um; Fragen zeigt ein Fenster: N JT-Modelle sind noch nicht umgewandelt (X MB). Geschätzte Zeit: etwa Y s. mit Umwandeln und laden / Ohne sie laden, dem Speicherort und Nicht mehr fragen (automatisch umwandeln); Nie lädt die JT-Dateien wie bisher direkt.
• Geschätzte Zeit (seit 2026-10-25): ein modelconv-Prozess braucht einen Aufwand pro Datei (Standard 0,3 s) plus Sekunden pro MB der JT-Datei (Standard 0,25 s/MB); die Prozesse laufen parallel (min(Kerne / 2, 4)); die Gesamtzeit ist nie kürzer als die längste Datei. Beide Faktoren lernen aus den Zeiten der Aufträge der letzten Umwandlungen auf diesem Rechner (Einstellungsschlüssel JT_Convert_JobSecPerFile, JT_Convert_JobSecPerMB; das alte JT_Convert_SecPerMB wird nicht mehr verwendet).
• An der Stelle der Entscheidung: das Fenster Available objects einer Studie hat den Bereich JT-Modelle als glTF (umwandeln ja / nein, Speicherort, Anzahl der umzuwandelnden Modelle der gewählten Komponenten, MB und geschätzte Zeit); die Einstellungen sind seine Standardwerte. Das Fenster liegt immer ganz auf dem Bildschirm: eine mit einer anderen Monitoranordnung gespeicherte Geometrie wird in den Bildschirmbereich verschoben / verkleinert (ebenso bei den anderen RCS-Fenstern mit gespeicherter Geometrie).
• Umwandlung: im Hintergrund, bis zur Hälfte der Prozessorkerne (höchstens 4) gleichzeitig, mit abbrechbarem Fortschrittsfenster JT models (abgebrochene Modelle werden aus den JT-Dateien geladen); seit 2026-10-25 schließt es sich sofort nach der Umwandlung (vorher blieb es bis zum Ende des Ladens auf 100 %). Das Meldungsfenster zeigt je Modell eine Zeile (Zeit, Dreiecke) und eine Zusammenfassung. Ohne Konverter: eine klare Meldung mit der zu ändernden Einstellung, danach werden die JT-Dateien direkt geladen – nie stillschweigend. Das Fortschrittsfenster Loading ... zeigt Free GPU memory nur, wenn die Ansicht diesen Wert liefert (nicht in der Variante ohne JT-Leser).
• JT-Datei, die der Konverter nicht lesen kann (seit 2026-10-25; z. B. ...ALLCATPART V3.jt neben der richtigen JT-Datei der Komponente im Ordner .cojt; modelconv Exitcode 2 – der JT-Leser findet kein Modell: Datei beschädigt oder nicht unterstützte JT-Variante): eine klare Meldung in der Konsole mit dem Dateikopf (JT-Version); hat die Komponente eine andere JT-Datei: the JT file '...' is skipped ... The component is shown from its other JT file. In diesem Programmlauf wird die Datei nicht erneut umgewandelt (bis sie sich ändert); die Schätzung zeigt N JT file(s) could not be read by the converter earlier and are skipped, API: unreadable in model_cache estimate, Zustand failed mit error in status.modelConversion.models.
• Modellbaum: der Tooltip eines umgewandelten Modells zeigt den Pfad der .glb und umgewandelt aus <JT-Datei>.
• Simulationsdatei: Docked verweist auf das umgewandelte Modell (jtFile = .glb) und behält die JT-Quelldatei in sourceJt. Eine solche Simulation lädt ohne JT-Datei und ohne Konverter, wenn die .glb existiert; ist die JT-Datei vorhanden und geändert, wird sie neu umgewandelt.

API: load, open, insert_study_robots und package_open nehmen convert ("auto", "ask" = wie auto ohne Fenster, "never"); das Ergebnis steht in status.modelConversion (converted, reused, failed, skipped, seconds, models); model_cache liest und setzt Modus und Speicherort und schätzt die umzuwandelnden Modelle einer Simulations- oder Studiendatei ohne Umwandlung (siehe API-Referenz); für eine Studie (.xml) neben estimate (Werkzeuge an den Robotern) auch estimateAll – alle Komponenten der Studie mit 3D-Modell, wie File → Open mit allen Objekten. open nimmt objects ("all" oder eine in Available objects gespeicherte Auswahldatei .ini).

Simulationspaket (*.rcsz)

File → Simulationspaket speichern (*.rcsz)... speichert eine ZIP-Datei mit allem, was zum Öffnen der Simulation auf einem anderen Rechner nötig ist: die Simulationsdatei, das SPS-Programm und die Einstellungen darin, die umgewandelten Werkzeugmodelle (.glb + .glb.json; ein als JT geladenes Werkzeug wird jetzt umgewandelt) und die Daten der Roboter. Alle Pfade im Paket sind relativ; das Manifest rcsz.json enthält Formatversion, Datum, DReS-Version, die Dateiliste, die Dateien jedes Roboters und die JT-Quelldateien nur mit Namen (keine Pfade des Kunden).

• Roboterdaten aufnehmen (Standard ein): nur die Daten, die die Simulation liest, nicht das ganze Archiv, in der Ordnerstruktur des Archivs (KRC\R1\..., C\KRC\...). KUKA: am.ini, ArchiveInfo.xml, der ganze Ordner KRC (Folgen, UPs, Makros, System mit $config.dat – Werkzeug- und Basisdaten, MADA mit $machine.dat / $robcor.dat, VW_User, TP, STEU mit $config.dat und Mada), die Maschinendatenordner Mada unter C\KRC\..., die Langtexte (Longtexts*, Langtext*) und ein WorkVisual-Projekt (*.wvs); nicht die Logdateien, die Registry und die übrigen Systemdateien (Station PSZ: etwa 8 MB je Roboter statt 25–30 MB). Fanuc: die .ls-Programme und die Dateien .va, .dg, .io, .dt, .txt, .csv, .xml, .ini (keine binären .tp / .vr / .sv). Aus: das Paket behält die Archivpfade dieses Rechners.
• Eigenständiges Paket: Das Paket enthält nie die Studiendatei und verweist auf keine Datei außerhalb (kein Systemstamm, keine Archivordner dieses Rechners). Die in der Szene geladenen Zellenkomponenten und die an den Robotern angebauten Werkzeuge und Vorrichtungen (auch die der Studie) werden als umgewandelte Modelle mit ihren Positionen gespeichert; das Öffnen des Pakets öffnet nie die Zelle der Studie. Vor dem Schreiben werden die Dateien des Pakets nach Pfaden dieses Rechners durchsucht; ein Paket, das nach außen verweisen würde, wird abgelehnt und die Pfade stehen in der Konsole.
• Original-Modelldateien als Quelle einschließen (Standard ein, Einstellung Simulation_Package_Source): die Original-Modelldateien liegen im Ordner models_src nur als Quelle, falls die Modelle erneut umgewandelt werden müssen; die Simulation öffnet immer die umgewandelten Modelle. Aus: das Paket ist kleiner (Station PSZ mit 5 Robotern und 10 Werkzeugen: 75 MB mit den Quellen, 26 MB ohne). Das Fenster zeigt die geschätzte Größe der Teile (Modelle, Quellen, Roboter und Einstellungen, gesamt; unkomprimiert, die Datei ist kleiner); die API package_save mit dryRun: true liefert dasselbe.
• Erscheint 10 s nach dem Öffnen eines Pakets kein Roboter in der Zelle, steht eine Warnung in der Konsole.

Montierte Elemente. Das Robotermenü Montierte Elemente listet das Werkzeug und die Vorrichtungen am Roboter; jedes hat Ausblenden / Einblenden (das Modell wird nicht gezeichnet; wird mit der Simulation und dem Paket gespeichert) und Vom Roboter entfernen (ein Modell aus einer Datei wird aus der Szene gelöscht, ein Element der Studie bleibt ausgeblendet). Ein ausgeblendetes Modell bleibt in den Kollisionsprüfungen (3D, Arbeitsbereiche, Blockaden); nur ein entferntes wird nicht mehr geprüft. Dasselbe Modell wird nie zweimal an einem Roboter angebaut (derselbe Name oder ein Name, der mit dem anderen an einem Unterstrich beginnt): beim Laden einer Simulation, eines Pakets oder einer Sitzung, nach Insert robots at study positions und mit dem Robotermenü Doppelte Modelle entfernen bleibt nur eines (das Element der Studie vor einem Modell aus einer Datei, eine Vorrichtung vor einem Werkzeug). Ein Dummy-Werkzeug gibt es nur für einen Roboter ohne 3D-Modell seines Werkzeugs; das Anbauen eines Modells entfernt das Dummy, und ein Dummy in einem älteren Paket oder einer älteren Simulation wird nicht geladen, wenn der Roboter ein Modell hat. API: tool_info, tool_remove, tool_hide, tool_show, tool_model (replace).

File → Simulationspaket öffnen..., File → Open, Load simulation... und die zuletzt geöffneten Dateien nehmen .rcsz: das Paket wird nach %LOCALAPPDATA%\DrAmaT\RCS\Packages\<Name>_<Schlüssel> entpackt (dieselbe Datei erneut: kein neues Entpacken) und seine Simulation geladen – die Roboter aus dem Ordner des Pakets, ohne die Originalarchive. Beispiel: die Station PSZ mit 5 Robotern und 2 Schweißzangen als glTF (45 MB) ergibt ein Paket von etwa 20 MB. API: package_save (file, includeRobotData, includeSource, dryRun) und package_open (file).

Das Paket enthält außerdem die Briefing-Datei AGENTS.md der Station an der Wurzel der ZIP-Datei (vor dem Speichern aktualisiert, wenn Simulation > AGENTS.md automatisch aktualisieren an ist; nicht vorhanden, wenn die Option aus ist und keine Datei existiert); beim Öffnen des Pakets wird sie zurückgelesen. Siehe AGENTS.md.

Plugin-Einstellungen > Simulation

Tools → Settings..., Registerkarte Simulation:

Plugin-Einstellungen, Registerkarte Simulation: Kollisionsmerker in Makros suchen, Zeitfenster der Wettläufe, Fenster am Ende und die Option Reihenfolge der Roboter bei einem Wettlauf während des Laufs beibehalten

Plugin-Einstellungen > Kollisionsbericht

Tools → Settings..., Registerkarte Kollisionsbericht, eine Option:

Plugin-Einstellungen, Registerkarte Kollisionsbericht: Benachbarte Punkte derselben Stelle als ein Fall

Befehls-API

Jede Option dieser Registerkarte kann auch ein Skript oder ein KI-Agent lesen und setzen: run, fast_run, sim_options, sim_action (Pause / Resume, Continue, Check interlock map), live_check und collision_ignore; die Einstellungen der Wettläufe mit race_rules, Vorschlag und Simulation beider Reihenfolgen mit race_study, die Option Gespeicherten Bericht ... öffnen mit report_open, den Modellkonverter mit model_converter, die Umwandlung der JT-Modelle mit model_cache, das Simulationspaket mit package_save / package_open, die zuletzt geladenen Simulationen mit recent_files (laden mit load) – siehe Befehls-API.

JT ist eine Marke der Siemens Industry Software Inc. Andere Marken gehören ihren jeweiligen Inhabern.