Wie die Simulation läuft
- Ein Thread je Roboter – jeder Roboter von Run on all robots läuft in einem eigenen Thread, das SPS-Programm der Station in einem weiteren Thread, so fahren alle Roboter wie in der realen Zelle gleichzeitig.
- Die Oberfläche auf einem eigenen Kern – während der Simulation läuft die Oberfläche (3D-Szene, SmartPad, Konsole, Tabellen) auf dem ersten Prozessorkern, die Roboter und die SPS auf den anderen Kernen: die Szene nimmt den Robotern keine Zeit weg und die Roboter blockieren die Szene nicht. Nach der Simulation nutzt die Oberfläche wieder alle Kerne. Die Konsole zeigt die Zuordnung, z. B. Prozessor: Oberfläche auf Kern 1 (2 logische Prozessoren), Roboter und SPS auf 5 Kern(en) (10 logische Prozessoren) von 6.
- Eigene Simulationsuhr – der Simulator rechnet mit einer eigenen Uhr, unabhängig vom Rechner: derselbe Ablauf ergibt bei 100 %, 200 % und 400 % und auf 2 oder 5 Kernen dieselben Taktzeiten. Ein zu langsamer Rechner macht nur die Animation langsamer als die eingestellte Geschwindigkeit – die Uhr wartet auf die Roboter, die Zeiten ändern sich nicht. Während der Simulation läuft der Systemtakt mit 1 ms (Windows), damit die Roboter-Threads unabhängig von anderen Programmen pünktlich aufwachen.
- Start in zwei Phasen – zuerst planen alle Roboter ihre Bewegung (die Uhr steht), dann startet die Uhr und alle Roboter fahren zusammen los; die Vorbereitung zählt nicht zur Simulationszeit (siehe Auf allen Robotern ausführen).
- Programmtimer (t1 (EIN) = 0[1/10Sek]) laufen wie auf dem Roboter: einmal gestartet, zählen sie auf der Uhr der Station bis t1 (EIN) = STOP – auch in der Pause des Roboters, bei kleinerer Geschwindigkeit, nach dem Ende der Folge und nach einer Satzanwahl in der laufenden Station; erst ein neuer Start der Simulation setzt sie auf null.
Prozessorkerne für die Roboter (Plugin-Einstellungen > Simulation): alle anderen = alle Kerne außer dem Kern der Oberfläche; eine Zahl begrenzt die Kerne der Roboter, z. B. für einen Test, wie die Simulation auf einem kleineren Rechner läuft.
Vorbereitung im Hintergrund
Nach dem Laden einer Studie oder Simulation, einer Änderung des SPS-Programms, des Programms der Registerkarte Simulation oder der Program rules bereitet der Simulator den Ablauf im Hintergrund vor, Schritt für Schritt, die Szene bleibt bedienbar (Konsole: Simulation wird vorbereitet ..., kleines Fenster mit Fortschrittsbalken in der Ecke):
- die Programme der Roboter (Folge und die daraus aufgerufenen UP, die Makros der Plugin-Einstellungen, Standard 20, 46, 47, 50, 57) werden einmal geparst und gespeichert – ein im SmartPad oder Editor geändertes Programm wird neu geparst,
- die Schrittlisten der Roboter (UP-Aufrufe, WARTE BIS, Verriegelungen, Regeln) werden mit den Optionen, von denen sie abhängen, gespeichert,
- die Beschreibungen der Verriegelungsbereiche und ihre Partnerroboter (Verriegelungskarte) werden aus den Archiven gelesen.
Der Start nimmt alles aus dem Speicher (Konsole: Roboter vorbereitet in 0.4 s: 5 Programm(e) aus dem Speicher, 0 jetzt geparst, Schrittlisten von 5 Roboter(n) aus dem Speicher); was sich inzwischen geändert hat, wird beim Start vorbereitet. Station A, 5 Roboter, Folge 81: Start 7 s → 0,4 s.
Start aus HOME
Nach dem Laden der Zelle stehen die Roboter nicht in HOME (Position von Punkt 1 der Folge). Vor der Simulation einmal Folge 125 (oder das HOME-Programm der Station) ohne SPS-Programm ausführen – die Roboter fahren nach HOME und der erste Zyklus der Simulation wird dann richtig gezählt.
Darstellung
Die Szene wird im Thread der Oberfläche gezeichnet (OpenGL). Die Roboter-Threads speichern nur die neue Position ihres Roboters; ein Timer der Oberfläche zeichnet alle fahrenden Roboter zusammen. Das Zeichnen bremst daher nie die Simulationsuhr – mit einer schwachen Grafikkarte ist die Animation weniger flüssig, die Zeiten bleiben gleich. Einstellungen der Grafikkarte und Grenzen: GPU und Grenzen.
Gemessen
Station A, 5 Roboter + SPS-Programm, Folge 81, 10 Zyklen, 400 %, Laptop Intel i7-8750H (6 Kerne, 12 logische Prozessoren), Roboter aus HOME gestartet:
| 5 Kerne für die Roboter | 2 Kerne für die Roboter | |
| Wirkungsgrad der Station | 84,1 % | 84,1 % |
| Warten auf Verriegelungen | 272,3 s | 272,3 s |
| Längster Roboter (R5) min / Mittel / max | 72,17 / 72,25 / 72,30 s | 72,17 / 72,22 / 72,29 s |
| Dauer des Ablaufs (Echtzeit) | 186 s | 186 s |
Die Zeiten hängen nicht von der Anzahl der Kerne ab (Unterschiede unter 0,1 s). Mit 5 Robotern und dem SPS-Programm nutzte die Simulation im Mittel weniger als einen logischen Prozessor – die Roboter-Threads warten meist auf die Uhr, die Verriegelungen und die Signale der Station, daher halten auch 2 Kerne 400 % mit.
Auslastung des Rechners
Station A (anonymisierte reale Station): 5 Roboter + SPS-Programm, Folge 81, 10 Takte (etwa 720 s Simulationszeit), Arbeitsbereiche aus den Dreiecken der 3D-Modelle, Laptop Intel i7-8750H (6 Kerne, 12 logische Prozessoren, 16 GB):
| 100 % | 400 % | 400 % + Live 3D (fester Schritt 20 ms, mehrere Kerne) | |
| Dauer des Laufs (Echtzeit) | 752 s | 188 s | 835 s |
| Prozessor, Mittelwert (ein logischer Prozessor = 100 %) | 73 % | 72 % | 373 % |
| Prozessor, Anteil am ganzen Rechner | 6 % | 6 % | 31 % |
| Speicher (Working Set), Maximum | 623 MB | 617 MB | 640 MB |
- Speicher: Plugin offen 445 MB, Station geladen 546 MB, Arbeitsbereiche berechnet 613 MB; die Simulation selbst braucht fast nichts dazu.
- Prozessor: ohne Live 3D braucht die Simulation etwa einen logischen Prozessor. Die Live-3D-Prüfung berechnet jede Prüfung auf mehreren Kernen (hier 6 Threads) – der Rest des Rechners bleibt nutzbar.
- Live 3D mit festem Schritt (Standard 20 ms): das Ergebnis hängt nicht von der Geschwindigkeit und vom Rechner ab; der Lauf wird länger, wenn der Rechner mit den Prüfungen nicht nachkommt (hier: 835 s statt 188 s, jede Bewegung nahe am Partner unter 70 mm). Messungen aller Modi und die empfohlenen Einstellungen: Live-3D-Kollisionsprüfung.
- Empfehlung: Suche nach Berührungen mit festem Schritt bei beliebiger Geschwindigkeit (400 % = kürzeste Dauer); ohne Live 3D für Taktzeiten.
Wie realistisch ist die Simulation?
Wofür sie gedacht ist. Der Robot Cell Simulator ist kein digitaler Zwilling der Station. Ein digitaler Zwilling bräuchte das laufende SPS-Programm der Station zusammen mit der Originalsoftware der Robotersteuerungen und ein vollständiges Modell der Zelle – ohne laufendes SPS-Programm ist das nicht möglich, und es ist auch nicht das Ziel. Der Simulator hilft, die Station auf einfache Weise in einem Werkzeug zu optimieren: aus den Roboterarchiven und der Studie sieht der Roboterprogrammierer, welcher Roboter die Taktzeit bestimmt, wer auf welchen Verriegelungsbereich wartet und wo Prozesszeiten oder Bereichsfreigaben verschoben werden können – ohne detailliertes Wissen über CAD-Modellierung oder SPS-Programmierung.
Die Simulationsuhr. Der Simulator rechnet mit einer eigenen Uhr, unabhängig vom Rechner: derselbe Ablauf ergibt bei 100 %, 200 % und 400 % Simulationsgeschwindigkeit dieselbe Taktzeit. Ein langsamerer Rechner macht nur die Animation langsamer, nicht die Zeiten anders. Die Vorbereitung vor dem Start (Programme, Bahnplaner) wird nicht in die Simulationszeit eingerechnet (siehe Start in zwei Phasen).
Die Robotersteuerung. Die KUKA-Steuerung arbeitet deterministisch (Interpolationstakt 12 ms); ihre Schwankungen liegen im Millisekundenbereich und müssen nicht simuliert werden.
Woher die Abweichungen kommen:
- Bahnplanung – der Planer verwendet die Maschinendaten des Roboters (Achsgeschwindigkeiten und -beschleunigungen) und die Bewegungsparameter des Programms, aber die Steuerung legt ihr dynamisches Modell nicht offen: die Beschleunigungen hängen von der Last ab (z. B. Werkzeuge mit 200–400 kg). Typische Abweichung der Bewegungszeit: 5–15 %.
- Signale und SPS – das SPS-Programm der Station ist ein vereinfachtes Modell (Folgenstart, Freigabe, Eingänge in HOME); der Zyklus der realen SPS, der Feldbus und die Handshakes werden nicht genau nachgebildet.
- Prozesszeiten – Schweißen, Zange, Spanner und andere Halte an Befehlen kommen aus den Program rules: das Ergebnis ist so gut wie die eingetragenen Zeiten.
- Halte auf der Bahn – ist das FB PSPS (Fahrbedingung) während einer Bewegung nicht mehr erfüllt, hält der simulierte Roboter sofort dort an, wo er ist; der Bremsweg wird nicht simuliert (der reale Roboter bremst auf der Bahn und braucht einen Moment, um wieder anzufahren). Die Bedingung wird alle 100 ms der Simulationsuhr geprüft (Plugin-Einstellungen), die Steuerung prüft alle 12 ms.
Der Vergleich von Varianten (vor / nach einer Änderung des Programms, der Reihenfolge der Roboter oder der Bereichsfreigaben) ist auch ohne Messungen zuverlässig, weil dieselben Abweichungen für beide Varianten gelten. Für absolute Taktzeiten lässt sich die Simulation mit Messwerten der realen Station vergleichen – in der SPS erfasste Taktzeiten und ein KUKA-Trace (Achspositionen mit Zeitstempel) einiger Roboter; mit solchen Messungen kann die Schätzung kalibriert werden.