Eine Simulation mit 100 % zeigt eine Reihenfolge der Roboter – die, die an der Anlage meistens vorkommt. Eine Bewegung ohne Verriegelung in einem mit einem anderen Roboter gemeinsamen Bereich ist dann oft nur wegen dieser Reihenfolge sicher. An der Anlage ändert sich die Reihenfolge: ein Roboter bleibt mit einem Fehler am Schweißpunkt stehen, ein Bauteilsensor kommt nicht, ein Roboter fährt alle n Takte zum Kappenfräsen, ein Roboter fährt langsamer. Der Reiter Robustness test (nach Simulation) führt eine Reihe von Simulationen der Station mit solchen Änderungen aus – aus einem Plan oder einem Zufallsgenerator, eine Stunde lang oder über Nacht – und schreibt in einen Bericht: Kollisionsgefahren, Berührungen der 3D-Modelle, Verklemmungen, Wartketten und ob die Station zur Taktzeit zurückkehrt.

Inhalt: 1. Vor dem Test · Wie die Roboter fahren · 2. Der Reiter und seine Optionen · Arbeitsbereiche oder 3D-Berührungen · 3. Plandatei · 4. Test ausführen · 5. Ergebnisse lesen · 6. Bericht · 7. Befehls-API

1. Vor dem Test

1. Station laden und das Programm des Reiters Simulation wählen (z. B. Folge 81). Der Test verwendet das Programm, das SPS-Programm und die Optionen des Reiters Simulation.
2. SPS-Programm (Reiter SPS): die Roboter werden wie an der Anlage gestartet (Folgenstart, Warten auf die Station). Ein mit seinem SPS-Teil gespeicherter Plan bringt das SPS-Programm beim Laden zurück.
3. Arbeitsbereiche (Reiter Arbeitsbereiche) der Programme der Folge: ohne sie sieht der Test die gemeinsamen Bereiche nicht – Langsam in den Bereichen und der Verzögerungstest wirken nicht, und es wird keine Kollisionsgefahr aus den Bereichen gefunden. Würfel sind schnell, Dreiecke der 3D-Modelle folgen der echten Form der Roboter (weniger Fälle am Rand eines Bereichs).
4. Optional Live-3D-Kollisionsprüfung auf dem Reiter Simulation: die 3D-Modelle der Roboter und Werkzeuge werden während des ganzen Tests geprüft (langsamer, am besten mit der Geschwindigkeit 100 %). Sie wirkt ab dem Start jeder Simulation – während des ganzen Tests eingeschaltet lassen.

Wie die Roboter im Test fahren

• Alle Roboter fahren dieselbe Folge – das Programm des Reiters Simulation, mit dem SPS-Programm die Folge des Stationsblocks jedes Roboters. Jeder Schritt ist ein Lauf auf allen Robotern mit N+1 SPS-Durchläufen (ein Startdurchlauf und N gemessene Takte).
• Die Schritte ändern nur das Timing: Geschwindigkeit eines Roboters, Halte in Punkten, langsame Bewegung in den gemeinsamen Bereichen, Startversatz, Serviceprogramme alle N Takte. So treten andere Reihenfolgen der Bewegungen derselben Folge auf als in der Simulation mit 100 %.
• UP-Aufrufe wie auf dem Reiter Simulation (UP calls, Program rules): ein ausgeschlossenes UP (z. B. Kappenfräsen) läuft nicht; ein Serviceprogramm der Tabelle Serviceprogramme läuft alle N Takte, auch wenn es ausgeschlossen ist. Mit Alle UP-Aufrufe läuft jedes UP der Folge in jedem Takt, und die Regeln Exclude UP werden während des Tests ignoriert (die Einstellungen des Reiters Simulation bleiben) – für die Kollisionsmatrix kann jedes UP laufen.
• Der Verzögerungstest (MISSING) nimmt jede Bewegung ohne Verriegelung aus dem Lauf (mit Alle UP-Aufrufe auch aus den UPs) und jeden Partner im gemeinsamen Bereich und verzögert den Partner oder den Roboter selbst – eine systematische Prüfung der Kombinationen der Bewegungen der Folge statt zufälliger.
• Die Arbeitsbereiche (gemeinsame Bereiche, rot / gelb) kommen aus allen Bewegungen der Folge und aller ihrer UPs, unabhängig von der Reihenfolge (Wie die Roboter in der Simulation fahren).

2. Der Reiter und seine Optionen

Plan – woher die Schritte kommen. Ein Schritt ist eine Simulation der Station mit einer Anzahl von Takten und seinen Einstellungen.

Serviceprogramme – Serviceprogramme suchen listet die UP-Aufrufe der Folge jedes Roboters (UPn = Bedingung, UPn = EIN mit Flags, REPEAT UPn; bedingte Aufrufe und REPEAT sind markiert – typische Serviceprogramme wie Kappenfräsen). Alle N Takte: das UP läuft nur in jedem N-ten Takt der Station (1 = jeder Takt wie im Programm, 0 = nie). Der Basislauf läuft ohne sie.

Halte in Punkten – Hinzufügen einer Zeile: Roboter, Programm (Folge oder UP), Punktnummer wie im Programm, Haltezeit, alle N Takte. Der Roboter bleibt direkt nach dem Erreichen des Punkts stehen – wie ein Fehler am Schweißpunkt oder ein Bauteilsensor, der nicht kommt. Gilt in allen Schritten, nicht im Basislauf.

Optionen

Arbeitsbereiche oder 3D-Berührungen – was findet welche Prüfung?

Der Test prüft zwei verschiedene Dinge. Keine der beiden Prüfungen enthält die andere – ein vollständiger Test nutzt beide (Option Nur Berührungen der 3D-Modelle aus).

• Arbeitsbereiche (Kollisionsgefahr ohne Verriegelung, MISSING): ein Roboter fährt ohne Verriegelung in einen mit einem Partner gemeinsamen Bereich, während der Partner zur selben Zeit in diesem Bereich ist. Die 3D-Modelle müssen sich in diesem Lauf nicht berühren – z. B. verlässt ein Roboter den Bereich gerade, während der andere einfährt, einen halben Meter voneinander entfernt. Heute schützt die Reihenfolge der Roboter die Bewegung; kommt einer von ihnen später (Halt an einem Schweißpunkt, fehlendes Teil, anderer Override), kollidiert dasselbe Paar. Die fehlende Verriegelung würde die Bewegung immer schützen – ohne sie hängt die Sicherheit nur vom Zeitablauf ab.
• Berührungen der 3D-Modelle (Live 3D): die Modelle der Roboter und Werkzeuge berühren sich wirklich (oder kommen näher als der Sicherheitsabstand) – aber nur im Zeitablauf dieses Laufs. Eine Bewegung ohne Verriegelung, die in diesem Lauf zu keiner Berührung führt, bleibt unsichtbar. Dafür findet die 3D-Prüfung auch Berührungen, die die Arbeitsbereiche nicht als Fehler zeigen: beide Roboter halten ihre Verriegelungen und berühren sich trotzdem (Verriegelungsbereich zu klein, zu früh freigegeben oder zu spät angefordert), oder die Arbeitsbereiche zeigen dort keinen gemeinsamen Bereich (Näherung eines Werkzeugs oder der Bereiche).

Beispiel aus einem Test einer Station mit fünf Robotern: 57 Fälle, davon 26 Berührungen der 3D-Modelle – die übrigen 31 waren Bewegungen ohne Verriegelung ohne Berührung in diesen Läufen. Mit Nur Berührungen der 3D-Modelle würden diese 31 Fälle im Bericht fehlen. Die Spalte Ursache des Berichts und des Fensters zeigt, welche der Situationen ein Fall ist.

Wann nur die 3D-Berührungen? Wenn die Bewegungen ohne Verriegelung bekannt sind (z. B. aus Check interlocks) und nur die gesucht werden, die wirklich in einer Berührung enden. Der Verzögerungstest (MISSING) geht einen Schritt weiter: er verschiebt den Zeitablauf der Roboter gezielt und zeigt für jede Bewegung ohne Verriegelung, ab welcher Verzögerung die Roboter kollidieren.

Der Reiter Robustheitstest während eines Tests: Plan mit drei Schritten, Optionen, Verzögerungstest (MISSING) mit Wer wartet und Verfeinerung, die geschätzte Restzeit und das Ende neben den Schaltflächen

3. Plandatei (JSON oder XML)

Die Roboter werden mit einem Teil ihres Namens angegeben (R04, 0001R04). Jeder Schlüssel ist optional.

{
  "seed": 3, "repeat": false, "ignoreCollisions": true, "stopOnCollision": false,
  "baseline": true, "baselineCycles": 1,
  "speed": 100, "timeLimitMin": 0, "maxCycles": 0, "recoveryTolerance": 5,
  "report": "D:/tests/psz",
  "startAt": "2026-10-16T22:00:00",
  "steps": [
    { "name": "R06 5 % in den gemeinsamen Bereichen", "cycles": 1,
      "zoneSlow": { "override": 5, "robots": ["R06"], "areas": "shared" } },
    { "name": "R06 haelt 30 s in UP42/P49", "cycles": 1,
      "holdAt": [ { "robot": "R06", "point": "UP42/P49", "sec": 30, "everyCycle": 1 } ] },
    { "name": "R04 50 %", "cycles": 2, "override": { "R04": 50 } },
    { "name": "Zufall", "cycles": 4, "random": { "override": [20, 100], "robots": ["R01", "R04"] },
      "startJitter": 3, "pause": { "prob": 0.2, "sec": [2, 8], "robots": ["R03"] } }
  ],
  "services": [ { "robot": "R06", "up": 101, "everyCycle": 10 } ],
  "stops":    [ { "robot": "R06", "point": "UP42/P29", "sec": 20, "everyCycle": 5 } ]
}

Dasselbe in XML:

<RobustTest seed="3" baseline="true" baselineCycles="1" speed="100" report="D:/tests/psz">
  <Step name="R06 langsam" cycles="1"><ZoneSlow override="5" robots="R06" areas="shared"/></Step>
  <Step name="R06 haelt" cycles="1"><HoldAt robot="R06" point="UP42/P49" sec="30" everyCycle="1"/></Step>
  <Step name="R04 50 %" cycles="2"><Override robot="R04" percent="50"/></Step>
  <Step name="Zufall" cycles="4"><Random min="20" max="100" robots="R01,R04"/>
    <StartJitter sec="3"/><Pause prob="0.2" min="2" max="8" robots="R03"/></Step>
  <ServiceUp robot="R06" up="101" everyCycle="10"/>
  <Stop robot="R06" point="UP42/P29" sec="20" everyCycle="5"/>
</RobustTest>

4. Test ausführen

• Test starten – oder zu einer Uhrzeit (Start um).
• Pause hält die Stationsuhr an (alle Roboter), der Test läuft mit derselben Schaltfläche weiter.
• Stopp beendet den Test, der Bericht wird mit den bis dahin fertigen Takten geschrieben.
• Gespeicherten Test fortsetzen... – nach jedem Schritt wird der Fortschritt im Berichtsordner gespeichert (rcs_robust_progress.json); ein gestoppter oder unterbrochener Test läuft ab dem nächsten Schritt weiter.
• Kollisionsgefahren... – die bisher gefundenen Fälle (Ignorieren, Roboter in die Punkte, Programme im Editor).
• Bericht schreibt den Bericht des bisherigen Tests und öffnet ihn (wenn Gespeicherten Bericht (HTML, PDF) im Standardprogramm öffnen in den Plugin-Einstellungen eingeschaltet ist).

Kollisionsgefahren...: die bisher gefundenen Fälle - Roboter ohne Verriegelung und sein Punkt, Partner und sein Punkt, ob der Partner eine Verriegelung hält, erstes Mal und Anzahl (Station mit anonymen Roboternamen)

Das Protokoll unter den Schaltflächen und die Konsole zeigen jeden Schritt: Overrides, Störungen, Taktzeiten, Kollisionsgefahren.

Neben den Schaltflächen: Rest: x min – Ende etwa hh:mm – mittlere Zeit der fertigen Schritte (oder Takte im laufenden Schritt) mal die restlichen Schritte; im Verzögerungstest die restlichen Versuche der Bewegungen; mit einem Zeitlimit höchstens bis zum Limit. Vor dem Ende des ersten Schritts: wird nach dem ersten Schritt geschätzt; ein Plan ohne Ende (Wiederholen, Zufallsgenerator ohne Limit): unbekannt. Dasselbe in der Statuszeile des Plugins und in der API (remainingMinutes, estimatedEnd).

Test unterbrechen und fortsetzen

1. Stopp (oder DReS schließen, oder der Rechner geht aus) – der Bericht der bis dahin fertigen Takte wird geschrieben.
2. Später: dieselbe Station laden, denselben Berichtsordner auf dem Reiter lassen (Feld Bericht automatisch speichern in) und Gespeicherten Test fortsetzen... drücken (API: robust_test {"action": "resume"}).
3. Der Test nimmt Plan und Optionen aus der Fortschrittsdatei (nicht vom Reiter), macht mit dem nächsten Schritt weiter und zählt Zeit, Takte und Kollisionsgefahren weiter. Die Zufallswerte laufen mit demselben Startwert weiter.
4. Verzögerungstest (MISSING): die Liste der Bewegungen ohne Verriegelung, die erreichte Verzögerung jeder Bewegung und die Halbierung werden gespeichert – der Test macht bei derselben Bewegung mit derselben Verzögerung weiter, statt mit der ersten zu beginnen.

Gespeichert wird nach jedem Schritt – ein in der Mitte unterbrochener Schritt wird wiederholt. Das geschätzte Ende in der Statuszeile rechnet ab dem fortgesetzten Stand.

5. Ergebnisse lesen

Welche Testart an einer realen Station welche Kollisionen findet (fester Plan, Zufallsgenerator, Plan eines KI-Agenten, Verzögerungstest): Vergleich der Testarten.

• Ein Fall nur in einem Schritt mit Störung, nicht im Basislauf: die Bewegung ist nur durch die Reihenfolge der Roboter geschützt. Eine echte Gefahr, wenn diese Störung an der Anlage vorkommen kann (ein Roboter bleibt in einem Punkt stehen, ein Bauteilsensor, ein Serviceprogramm). Lösung: eine Verriegelung (Anforderung vor der Einfahrt in den Bereich, Freigabe nach der Ausfahrt).
• Ein Fall schon im Basislauf, der an der Anlage nicht vorkommt: höchstwahrscheinlich die Näherung eines Dummy-Werkzeugs oder des Arbeitsbereichs – die Teile in der nächsten Annäherung der Live-3D-Prüfung prüfen (dummy tool, dummy body flange-TCP) und die 3D-Modelle der echten Werkzeuge laden.
• Langsam in den Bereichen ist eine künstliche Störung (an der Anlage gilt der Override für das ganze Programm eines Roboters); ein damit gefundener Fall zeigt, wo die Reihenfolge eine Bewegung schützt – vor einer Programmänderung mit einem Halt im Punkt (Halte in Punkten) bestätigen.

6. Bericht

HTML, PDF und JSON mit dem Datum im Namen (rcs_robust_yyyyMMdd_HHmm) im Berichtsordner. Der gespeicherte Bericht öffnet sich im Standardprogramm nur, wenn die Option Gespeicherten Bericht (HTML, PDF) im Standardprogramm öffnen eingeschaltet ist (Plugin-Einstellungen > Simulation, Standard: ein; API report_open) – ausschalten, wenn ein KI-Agent oder ein Skript den Test fährt. Inhalt:

• Zusammenfassung: Basislauf, minimaler / maximaler Stationstakt, Anzahl Kollisionsgefahren, Läufe mit Fehler (Verklemmung), gleichzeitige Anforderungen (RACE) und Wartketten;
• Diagramm des Stationstakts pro Takt über den ganzen Test – rot: Takte mit Störung, grüne Linie: Basislauf;
• Tabelle der Schritte: Overrides, Störungen (Roboter, Art, Sekunden, Takt), Taktzeiten, Warten, Rückkehr zur Taktzeit, neue Kollisionsgefahren, Fehler;
• Kollisionsgefahren aller Schritte, jeder Fall als ein Block: Roboter ohne Verriegelung und Punkt, Partner und Punkt, wie oft und in wie vielen Schritten, Geschwindigkeiten der Roboter und Achsen beim ersten Fund, zwei Bilder nebeneinander: die Ansicht der Simulation und eine Ansicht von oben mit dem Ort der Kollision in einem roten Kreis (3D-Berührung: der Berührungspunkt, Gefahr aus den Arbeitsbereichen: zwischen den TCPs beider Werkzeuge); nach den Bildern kehrt die Kamera zur Ansicht der Simulation zurück;
• Berührungen der 3D-Modelle: eigener Abschnitt mit den sich berührenden Teilen (Arm, Werkzeug, Dummy-Werkzeug) und dem Abstand;
• Verzögerungstest (MISSING): kürzeste Verzögerung mit Kollision pro Bewegung;
• Protokoll des Tests.

Ein Fall des Berichts: links die Ansicht der Simulation, rechts die Ansicht von oben mit dem Ort der Kollision im roten Kreis (Namen der Roboter für die Dokumentation ausgeblendet)

Der Abschnitt Wettläufe und Interlock priority des Berichts zeigt für jeden Schritt die Wettläufe (Bereich, beide Roboter mit den Punkten, wie oft, kleinster Zeitabstand, Gewinner), die Regeln des Schritts (SPS-Bausteine Interlock priority, raceOrder, API, auto – beim Wettlauf beibehaltene Reihenfolge) und jede Anwendung einer Regel; eine rote Zeile bedeutet, dass ein Roboter später als das Fenster war und sich die Reihenfolge der Roboter in diesem Schritt geändert hat (nicht zufällig, sondern durch die Störung). Über der Tabelle: Anzahl der Wettläufe, der beim Wettlauf hinzugefügten Regeln und der Reihenfolgeänderungen. Ergebnisse: siehe Wettläufe und Variante B.

Der Zeitenbericht eines einzelnen Laufs (Times > Report) enthält dieselben Angaben in zwei Abschnitten, Anforderungen im selben Moment (Wettläufe) und Interlock priority in diesem Lauf:

Wettläufe und Interlock priority im Zeitenbericht: Bereich 1, 0001R05 gewinnt mit 0,490 s Vorsprung, 0001R03 wartet 8,4 s; der SPS-Baustein hält diese Reihenfolge (Fenster 1,0 s)

7. Befehls-API

{"cmd": "robust_test", "action": "load", "file": "..."} (Teile: services, stops, sps, program – true / false), "save", "find_services", "start", "pause", "continue", "stop", "resume" (gespeicherten Test fortsetzen), "status" (active, finished, Schritt, Takte, Kollisionsgefahren, Minuten, Bericht), "risks" (Fälle mit Roboter, Punkt, Partner, Anzahl, erste Zeit und Schritt), "report" (auch "progress": "<Ordner>" – Bericht eines gespeicherten Tests). Live 3D: {"cmd": "live_check", "on": true, "cell": 20, "capsule": 60, "range": 200, "warn": 50} – die Antwort enthält die nächste Annäherung jedes Paares (closest). Arbeitsbereiche: {"cmd": "zones", "programs": ["folge81"], "mode": "triangles"}. Der Test ist zu Ende, wenn status.active false ist. Siehe Befehls-API.

Top