DReS Robot Cell Simulator - Werkzeuge an den Robotern: Anbauen, Wechseln, Werkzeugwechsel UP81 (YouTube, Deutsch)Werkzeuge an den Robotern
Beim Öffnen einer Zelle werden die Werkzeuge, die in der Studie an den Flanschen sitzen, an die Roboter angebaut. Die Spalte Attached to des Model Browser und die Liste in der Registerkarte Work Zones zeigen das aktuelle Werkzeug jedes Roboters. Werkzeuge werden von Hand über das Kontextmenü eines Roboters oder eines Werkzeugs gewechselt:
- Attach to robot... – baut das gewählte Werkzeug an einen ausgewählten Roboter an,
- Detach, Detach tool, Detach fixtures – lassen das Werkzeug (die Vorrichtungen) an der aktuellen Stelle zurück,
- Attach default tool – stellt das Werkzeug aus der Studie wieder her.
Komponenten, die ein Werkzeug sein können (Greifer, Zangen, Dockingsysteme, in der Studie montierte Komponenten), haben im Model Browser ein Hammersymbol: grau = frei, orange = an einen Roboter angebaut, rot durchgestrichen = in dieser Sitzung gegenüber der Studie geändert. Das Standardwerkzeug ist das Werkzeug, das in der Studie am Roboter montiert ist.
Der Dialog Attach legt den Roboter, Tool oder Add fixture (z. B. ein Bauteil im Greifer) und die Einbaulage am Flansch fest (X Y Z, A B C). Schaltflächen füllen die Lage aus:
- Position from the study – die in der Studie gespeicherte Einbaulage,
- Keep the position in the cell – die Komponente bleibt genau dort, wo sie in der Ansicht ist,
- Model origin on the flange – nur wenn der Ursprung des Werkzeugmodells auf dem Flansch liegt,
- Same as the current tool – die Lage des vorherigen Werkzeugs.
Prüfen Sie das Ergebnis, indem Sie A6 bewegen. Enthält die Studie eine vollständige Montagekette (Werkzeugwechsler → Adapter → Werkzeug), wird die ganze Kette automatisch angebaut. Das Robotermenü in der Liste Work Zones bietet dieselben Funktionen: Attach a tool... / Change the tool..., Add a fixture on the flange..., Detach tool, Show the tool in the model tree, Attach default tool.
Das Abbauen aller Werkzeuge und das Anbauen der Standardwerkzeuge aller Roboter befindet sich in der Registerkarte Auto-Docking.
Werkzeugmodell aus einer JT-, glTF-, STL- oder STEP-Datei
Das Kontextmenü eines Roboters (Model Browser) hat den Eintrag Werkzeugmodell (JT / STEP / STL / glTF)... (englische Oberfläche: Tool model (JT / STEP / STL / glTF)...). Der Dialog fragt nach:
- Modelldatei – das JT-Modell des Werkzeugs (z. B. einer Schweißzange) oder eine glTF-2.0- (.gltf mit ihrer .bin oder .glb), binäre STL- (.stl) bzw. STEP-Datei (.stp, .step); ... öffnet den Dateidialog im zuletzt benutzten Ordner,
- X Y Z [mm], A B C [deg] – die Lage des Modellursprungs relativ zum KUKA-Flansch ($FLANGE, KUKA ABC; 0 = das Modell liegt im Flanschkoordinatensystem). Das ist die Anbaulage, nicht der TCP ($TOOL_DATA): in einer Process-Simulate-Studie ist es die mountLocation (mm) / mountRotation des Werkzeugs (Schweißzangen am Werkzeugwechsler meist Z 38, A B C 0). Der CAD-Flansch des KUKA-Robotermodells ist um 180° um Z gedreht; der Simulator rechnet die Lage selbst um,
- Kontrollkästchen zusätzliches Element am Flansch (Vorrichtung, z. B. Werkzeugwechsler) – das Werkzeug bleibt – ohne Haken ist das Modell das Werkzeug des Roboters: es ersetzt das Werkzeug am Flansch, ein Dummy-Werkzeug wird entfernt; mit Haken ist das Modell ein zusätzliches Element (Vorrichtung) und das aktuelle Werkzeug bleibt.
Das Werkzeugmodell wird für die Arbeitsbereiche und die 3D-Kollisionsprüfung wie jedes andere Werkzeug verwendet. Trägt der Roboter schon ein Werkzeugmodell, öffnet sich der Dialog mit dessen Datei und Lage, sodass die Lage korrigiert werden kann. Das Meldungsfenster zeigt das angebaute Modell mit seiner Lage und dem Pfad der Datei.
Ein Modell nur einmal, kein Dummy mit Modell. Dasselbe Modell (derselbe Name oder ein Name, der mit dem anderen an einem Unterstrich beginnt) wird nie zweimal an einem Roboter angebaut: die API tool_model liefert einen Fehler mit den angebauten Elementen (replace: true ersetzt es), und das Robotermenü Doppelte Modelle entfernen behält eines (das Element der Studie zuerst). Ein Roboter mit 3D-Modell seines Werkzeugs hat kein Dummy-Werkzeug.
Montierte Elemente. Das Robotermenü Montierte Elemente hat ein Untermenü für das Werkzeug und jede Vorrichtung: Ausblenden / Einblenden (das Modell wird aus- oder eingeblendet; 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; nur ein entferntes wird nicht mehr geprüft. API: tool_info, tool_remove, tool_hide, tool_show.
Das Werkzeugmodell wird mit der Simulation gespeichert (Save simulation...: Element Docked mit dem Pfad im Attribut jtFile, auch für glTF-/STL-/STEP-Dateien) und mit der Sitzung (attached[].file): beim Laden wird die Modelldatei erneut eingefügt und das Modell mit der gespeicherten Lage angebaut. Relative Pfade werden auch aufgelöst, wenn das Simulationspaket in einen anderen Ordner verschoben wurde; eine nicht gefundene Datei wird im Meldungsfenster aufgeführt.
Beispiel: eine Punktschweißzange EuroX an Roboter R5 – der Ursprung des JT-Modells liegt 38 mm hinter dem Flansch, also Lage X 0, Y 0, Z 38, A B C 0. Der TCP des Roboters ($TOOL aus dem Roboterarchiv) liegt dann auf der Spitze der festen Elektrode; prüfen Sie das mit robot goto in einem Schweißpunkt (siehe unten) oder durch Bewegen von A6.
glTF, STL und STEP: das Modell muss im selben Koordinatensystem wie das JT-Modell liegen (z. B. aus der JT-Datei konvertiert), dann ist die Lage am Flansch dieselbe wie für die JT-Datei (z. B. Z 38). glTF 2.0 behält die Farben der Teile (die ursprüngliche JT-Farbe extras.jtDiffuse vom Konverter jt2step, sonst der lineare baseColorFactor der Materialien, nach sRGB umgerechnet – dieselben Farben wie im JT-Modell; Teile gleicher Farbe bilden ein Teil im Modellbaum); die Koordinaten sind laut glTF-Standard in Metern mit +Y nach oben und werden in Millimeter mit +Z nach oben umgerechnet. Unterstützt: Dreiecke (Modus 4), Float-Positionen, Normalen, 8-/16-/32-Bit-Indizes, Knotenmatrizen und Translation / Rotation / Skalierung; Dateien mit erforderlichen Erweiterungen (z. B. Draco-Kompression) oder Sparse-Accessoren werden mit einer Meldung abgelehnt. Eine glTF- oder STL-Datei wird Dreieck für Dreieck verwendet (eine Schweißzange mit 800 000 Dreiecken in etwa einer Sekunde) – STL hat keine Farben, das Modell wird einfarbig gezeigt. Eine STEP-Datei nur aus Dreiecken (Flächen mit einem POLY_LOOP aus 3 Punkten, z. B. aus JT konvertiert) wird direkt gelesen (etwa 30–60 s für 500 000–800 000 Dreiecke); jede andere STEP-Datei wird wie die Robotermodelle der Bibliothek trianguliert (Sehnenfehler 1 mm), was bei großen Modellen sehr lange dauert. Die Dreiecke der Datei werden für die Arbeitsbereiche aus Dreiecken und die Live-3D-Kollisionsprüfung verwendet, wie die Dreiecke eines JT-Modells. Das Meldungsfenster zeigt die Anzahl der Dreiecke und die Lesezeit. In einer Sitzung wird das Modell nur einmal gelesen. Verwendet werden nur die feinsten Dreiecke der Datei, ein JT-Modell bringt dagegen auch seine einfacheren Detailstufen (LOD) mit, die Live 3D alle verwendet – die Ergebnisse eines JT-Modells und einer STEP-/STL-Kopie können sich daher leicht unterscheiden. Das JT- und das STEP-/STL-Modell gleichen Namens sind verschiedene Komponenten (ID TOOLMODEL_<Roboter>_<Name>_stp, _step, _stl, _gltf oder _glb).
Per Skript oder KI-Agent: der Befehl
{"cmd":"tool_model","robot":"R5","file":"D:/.../zange.jt","pos":{"x":0,"y":0,"z":38,"a":0,"b":0,"c":0}} macht
dasselbe wie der Menüeintrag: das Modell wird eingefügt und am Flansch angebaut, es ersetzt das Werkzeug am Flansch (ein
Dummy-Werkzeug wird entfernt) und wird mit der Simulation und der Sitzung gespeichert; "fixture":true baut es
als zusätzliches Teil an. Derselbe Befehl ohne file verschiebt nur das schon angebaute Werkzeugmodell auf eine neue
pos. Zur Prüfung des Werkzeugs stellt
{"cmd":"robot","robot":"R06","goto":"UP42/P17"} den Roboter in einen Punkt des Programms (z. B. einen
Schweißpunkt), ohne das Programm zu starten; die Antwort von robot enthält das Werkzeug am Flansch (tool: id,
name, x..c) und die Position des Flansches in der Szene (flange: [x, y, z] mm, z. B. als target von
view für den Zoom auf das Werkzeug). Ein Werkzeugmodell aus mehreren Teilen (z. B. eine Schweißzange) behält die
Lage jedes Teils aus dem JT-Baum. Details: Befehls-API, Fenster KI-Agent.
Roboter an Studienpositionen einfügen
Datei → Roboter an Studienpositionen einfügen... (File → Insert robots at study positions...) fügt die Roboter der Studie aus ihren Archiven an den in der Studie gespeicherten Positionen ein. Das Archiv jedes Roboters wird automatisch verknüpft: ein Ordner oder eine ZIP-Datei mit dem Roboternamen im Ordner der Studie wird übernommen, auch wenn auf den Roboternamen noch ein Zusatz folgt (z. B. ...r01rs--kux). Eine ZIP-Datei wird in den Cache-Ordner des Benutzers entpackt (die Dateien des Benutzers bleiben unverändert; erneut entpackt wird nur, wenn die ZIP-Datei neuer ist). Das verknüpfte Archiv erscheint als kleines Archivsymbol in der zweiten Spalte (Attached to) des Model Browsers neben dem Roboter; der Tooltip zeigt den Ordner bzw. die ZIP-Datei des Archivs (und den Ordner, in den sie entpackt wurde). Ein Roboter, der nicht simuliert werden kann, wird als graues Modell eingefügt, siehe Roboter, die nicht simuliert werden können.
Das SPS-Programm (Registerkarte SPS) wird in den Einstellungen gespeichert, daher kann es nach dem Einfügen noch das Programm einer anderen Station sein. Ist kein Roboter des SPS-Programms in der Zelle, wird es durch ein neues Programm mit den Robotern der Zelle ersetzt (wie New from the robots of the cell; die Konsole schreibt eine Warnung mit den alten Robotern). Fehlen nur einige Roboter des Programms, bleibt das Programm erhalten, und die Konsole warnt, welche Roboter nicht in der Zelle sind – das Programm prüfen (SPS > Edit).
Nach dem Einfügen läuft automatisch die Basenprüfung: Die Basen der Studie werden mit den Basen in den Roboterarchiven verglichen, das Ergebnis steht in der Konsole (die Zusammenfassung des Einfügens nennt die Anzahl der abweichenden Basen).
Basen gegen die Studie prüfen
Datei → Basen gegen die Studie prüfen... (File → Check bases against the study...) vergleicht die Basen der Process-Simulate-Studie mit den Basen in den Roboterarchiven. Die Studie enthält die Sollwerte, das Archiv die gemessenen Werte (Einmessung des Tisches bzw. der Stationsbasis, z. B. FZG-Null der Station). Eine große Abweichung bedeutet, dass die Vorrichtungen der Studie und die Punkte des Archivs dort nicht zusammenpassen – die Simulation eines Roboters läuft dann an einer anderen Stelle als der Roboter in der Zelle.
- Studie: die Frames am Roboterelement ir_<Roboter> der Studie (systemFrames) – KUKA-Roboter: Frames b1, b2 ..., Fanuc-Roboter: User Frames uf1, uf2 ...
- Archiv: KUKA $BASE_DATA[n] aus $config.dat, auch Basen eines externen TCP (Basistyp #TCP, Werkzeug auf einem Ständer); Fanuc User Frames UF[n].
Geprüft wird gegen die Studie, aus der die Roboter eingefügt wurden (Roboter an Studienpositionen einfügen); ohne sie fragt das Programm nach der Studiendatei. Das Fenster hat folgende Felder:
- Toleranz Position (Standard 2 mm) und Toleranz Drehung (Standard 0,2°) – eine Basis mit größerer Abweichung wird als Warnung markiert.
- Bericht: Projekt, Ort, Kunde, Team, Station, Kommentar – erscheinen im Kopf des Berichts und bleiben für den nächsten Bericht gespeichert; Bericht mit der aktuellen 3D-Ansicht fügt ein Bild der 3D-Ansicht im aktuellen Zustand hinzu.
- Prüfen speichert die Toleranzen und prüft die Basen – Ergebnis in der Konsole, ein kurzes Fenster meldet das Ende der Prüfung; Prüfen und Bericht speichern... speichert zusätzlich den Bericht als PDF oder HTML (nach der Dateiendung) und öffnet ihn; Abbrechen schließt ohne Prüfung.
Die Konsole schreibt je Roboter und Basis eine Zeile: die Abweichung des Archivs von der Studie in mm (X, Y, Z im Roboterkoordinatensystem) und in Grad (Warnung über der Toleranz), eine Zeile je gemeinsamer Basis der Station und eine Zusammenfassung.
Bericht (im Stil der Berichte der Plugins VKRC / VFanuc Calibration): Logo aus den Druckeinstellungen, Kopf mit den Projektdaten, Datum, Studie und Toleranz, eine kurze Erklärung und die Tabellen:
- Basen der Roboter – je Roboter und Basis drei Zeilen: Studie (Soll-Frame), Archiv (gemessener Frame) und Differenz, jeweils mit X Y Z [mm] und A B C [°]. KUKA: bezogen auf den Roboterfuß wie $BASE_DATA; Fanuc: bezogen auf die Welt des Roboters wie UF. Dann |d| [mm] (Betrag der Positionsabweichung), Drehung [°] (Winkel zwischen beiden Orientierungen) und OK / prüfen gegen die Toleranz. Eine Basis eines externen TCP erscheint als n (ext. TCP), ein Fanuc User Frame als UF[n].
- Gemeinsame Basen der Station – Basen verschiedener Roboter, die in der Studie an derselben Stelle liegen (näher als 1 mm, die Nummer der Basis kann sich zwischen den Robotern unterscheiden), z. B. FZG-Null für alle Roboter der Station. Streuung [mm] zeigt, wie weit die Archive der Roboter diese Basis auseinander legen (Größte zwischen: die beiden Roboter mit dem größten Abstand) – eine Streuung über der Toleranz bedeutet, dass die Basis eines Roboters oder die Position des Roboters in der Zelle nicht richtig eingemessen ist.
- Roboter der Studie, die nicht in der Szene sind, stehen unter den Tabellen; optional: die 3D-Ansicht.
Lizenz: Die Basenprüfung (Menü, automatische Prüfung und API) benötigt die Basislizenz des Robot Cell Simulators (140).
API: Befehl base_check (Toleranzen, Berichtsfelder, Berichtsdatei, Ergebnis als JSON). Siehe auch das Plugin VKRC Calibration (Einmessen des Tisches mit den Punkten der Schilder MBxx X/Y/Z und einer Messspitze). Ein Einmessen des Tisches mit Messpunkten direkt im Robot Cell Simulator ist geplant.
Fanuc-Roboter (VW-Standard)
Seit 2026-10-20 übernimmt der Simulator auch Fanuc-Roboterarchive. Ein Roboterarchiv mit system.va und .ls-Programmen, aber ohne $config.dat, wird automatisch als Fanuc-Archiv (VW-Standard) erkannt – beim Laden aus der Simulationsdatei (ArchiveRobot), mit Datei → Roboter aus Archiv einfügen (File → Insert robot from archive) und beim Wiederherstellen einer Sitzung. Für die Simulation übersetzt RCS das Archiv in ein Ersatz-KUKA-Archiv im Cache-Ordner des Benutzers %LOCALAPPDATA%\DrAmaT\dres_<Version>\cache\RCS_fanuc\<Roboter>; die Dateien des Fanuc-Archivs bleiben unverändert, und die Simulationsdatei und die Sitzung behalten den Pfad des Fanuc-Archivs. Die Konsole meldet beim Laden Fanuc archive - translating the programs for the simulation, danach den Robotertyp und die Anzahl der Programme und Punkte. Wie die Programme übersetzt werden und was nicht simuliert wird: Fanuc-Programme in der Simulation.
- Kinematik – aus SYMOTN.VA (DH-Daten der Bewegungsgruppe 1). Die Umrechnung der Achsen zwischen Fanuc und dem KUKA-Modell ist exakt (dasselbe kinematische Modell) und wird bei jedem Laden geprüft; schlägt die Prüfung fehl, wird der Roboter nicht eingefügt (Fehler in der Konsole). Zusätzlich wird die Kinematik mit der von der Steuerung in SYMOTN.VA gespeicherten Position ($MCH_ANG, $MCH_POS, $UTOOL) verglichen: passt das Modell nicht (z. B. ein Fanuc-Roboter mit Parallelarm eines noch nicht bestätigten Typs) oder fehlen die Steuerungsdaten, wird der Roboter nicht simuliert eingefügt.
- Parallelarm (M-900) – die Fanuc-M-900-Roboter mit Parallelarm M-900iA/260L, M-900iB/280L und M-900iB/400L werden simuliert: der Versatz des Unterarms ist mit der von der Steuerung gespeicherten Position und mit dem CAD-Modell bestätigt, und die Bibliothek enthält ihre 3D-Modelle. Andere Parallelarm-Typen bleiben nicht simuliert, bis sie bestätigt sind.
- Verfahrachse (Achse 7 der Gruppe 1) – wird als Linearachse E1 entlang der X- oder Y-Achse der
Welt simuliert. Die Richtung der Fahrbahn kommt in dieser Reihenfolge aus
- der von der Steuerung gespeicherten Position in SYMOTN.VA (die Steuerungsposition ist genau um E1 verschoben),
- wenn die Steuerungsposition keine Richtung ergibt (E1 steht nahe 0, oder Achswinkel und gespeicherte Position stammen aus verschiedenen Zeitpunkten), der Steuerungskonfiguration $SCR_GRP[1].$EXT_XYZ_MAP (1 = X, 2 = Y, 3 = Z, positive Richtung),
- nur wenn auch diese fehlt, dem Robotertyp in der Process-Simulate-Studie (z. B. ein Typ, der auf _7ACHSE_Y+ endet).
- Darstellung der Verfahrachse – enthält die Process-Simulate-Studie ein Modell der Fahrbahn
(Mechanismus .m in der Bibliothek der Studie), wird dieses Modell gezeigt. Ohne CAD-Modell der Fahrbahn
zeichnet RCS sie als transparenten Quader über die Software-Endschalter von E1 (+500 mm): die Richtung + rot,
die Richtung - blau, ein Querbalken bei E1 = 0 und die Koordinatensysteme $ROBROOT (bei E1 = 0) und
$ERSYSROOT.
Fanuc-Roboter auf einer Fahrbahn ohne CAD-Modell der Fahrbahn: transparenter Quader über die E1-Grenzen, Richtung + rot, Richtung - blau - Signalbeschreibungen – die Kommentare der Signale in DIOCFGSV.IO (Kommentartabellen mit Signaltyp und Index) werden als Langtexte des Roboters verwendet: DI n = E n, DO n = A n. Die Verriegelungskarte findet daraus die Partnerroboter, z. B. DI 41 "L.Ant.1>R1" = Freigabe vom Partnerroboter R1. Ohne die Datei warnt die Konsole DIOCFGSV.IO not found - no signal descriptions for the interlock map.
- Werkzeuge und Basen – UT n = Werkzeug n (UT 0 = Werkzeug 32); UF n = Basis n+1. Die Fanuc-Welt liegt $MOUNT_LOC.Z über dem Roboterfuß.
- Punkte behalten X Y Z W P R; die Armkonfiguration kommt aus CONFIG (einschließlich der Turn-Zahlen). Als Achsstellung geteachte Punkte werden ebenfalls umgerechnet.
- Nicht unterstützte Montage – Roboter, die nicht bodenmontiert sind ($MOUNT_ANGLE), mit $MOUNT_LOC nicht nur in Z, ohne DH-Daten oder nicht 6-achsig werden nicht eingefügt (Fehlermeldung); Roboter auf einer Verfahrachse, die die Steuerungsposition nicht bestätigt, werden nicht simuliert eingefügt – der Simulator rechnet einen solchen Roboter nie mit fehlenden Daten.
- 3D-Modell – das Bibliotheksmodell aus cad.rcc wird nach dem Robotertyp gewählt ($SCR / Version ROBOT_ID, z. B. R-2000iB/210F, R-2000iC/210F, R-2000iC/270F, M-900iA/350, M-900iA/260L, M-900iB/280L, M-900iB/400L). Die Fanuc-Modelle haben keine Referenzdaten, daher werden ihre Maße nicht mit dem Archiv verglichen – die Simulation verwendet die Kinematik aus SYMOTN.VA. Andere Robotertypen erhalten das kinematische Modell (no CAD).
Roboter, die nicht simuliert werden können
Ein Roboter, dessen Positionen nicht korrekt berechnet werden können, wird in der Zelle angezeigt, aber nie mit falschen Positionen simuliert. Das gilt für
- einen Roboter auf einer Linearachse (Gruppe 1, Achse 7), deren Fahrbahnrichtung nicht bekannt ist – eine Fanuc-Verfahrachse wird als Linearachse E1 simuliert, wenn die von der Steuerung in SYMOTN.VA gespeicherte Position genau um E1 entlang der X- oder Y-Achse der Welt verschoben ist, oder (mit der Option Deduce the direction of the travel track (axis 7) of a robot that has one) wenn die Richtung aus $SCR_GRP[1].$EXT_XYZ_MAP oder aus dem Robotertyp in der Studie kommt; der Grund zeigt die gemessene Verschiebung (oder dass Achse 7 keine Position hat, nahe E1 = 0 steht oder keine Software-Endschalter in der Sicherung hat),
- einen Roboter, dessen Kinematik nicht zur von der Steuerung gespeicherten Position passt – z. B. Fanuc-Roboter mit Parallelarm eines noch nicht bestätigten Typs (bestätigt und simuliert: M-900iA/260L, M-900iB/280L, M-900iB/400L): die aus den Achswinkeln der Steuerung berechnete Position weicht von $MCH_POS ab,
- eine Sicherung ohne Steuerungsdaten in SYMOTN.VA ($MCH_ANG / $MCH_POS / $UTOOL) – die Kinematik kann nicht geprüft werden.
Ein solcher Roboter wird als statisches graues Modell mit dem Titel <Archiv> (not simulated) in der Nullstellung an seinem Platz in der Studie eingefügt. Der Model Browser zeigt ein rotes Verbotszeichen und den kurzen Grund in der zweiten Spalte (Attached to), z. B. not simulated: linear unit (axis 7) not confirmed oder not simulated: kinematics differs by 500 mm; der Tooltip zeigt den ganzen Grund. Seine Programme werden nicht geladen, und der Roboter ist nicht Teil der Abläufe, der Verriegelungsprüfungen und der Berichte; die Zusammenfassung des Einfügens zählt ihn als nicht eingefügt. Wird der Roboter im Model Browser ausgewählt, schreibt das Message Window den vollständigen Grund – die Werte der Steuerung (Achswinkel, von DReS berechnete und von der Steuerung gemeldete Position) und was zu tun ist (z. B. eine vollständige Sicherung verwenden).
Was das für Sie bedeutet:
- Der graue Roboter zeigt nur das Layout der Zelle. Für ihn werden keine Kollisionen, Arbeitsbereiche, Taktzeiten oder Berichte berechnet, und er bewegt sich nie.
- Partnerroboter, die auf seine Signale warten (Verriegelungsfreigaben, Handshakes), warten in der Simulation oder werden durch die Optionen des Ablaufs freigegeben – solche Wartezeiten auf einen nicht simulierten Roboter sind keine Programmfehler der Partner.
- Um den Roboter zu simulieren: eine vollständige Sicherung laden (mit SYMOTN.VA und der Steuerungsposition), einen Roboter eines bestätigten Typs verwenden oder – bei einer Verfahrachse – die Option Deduce the direction of the travel track (axis 7) of a robot that has one einschalten und den Roboter neu laden.
Registerkarte Robot Axis
 |
Die Registerkarte bewegt den aktuellen Roboter (im Model Browser ausgewählt). Die Schieberegler und Eingabefelder stellen die Achsen A1–A6 und die Linearachse E1 innerhalb der Grenzen aus den Maschinendaten ein. Der Roboter folgt sofort in der 3D-Ansicht. Keep TCP position when moving E1 kompensiert die 7. Achse: Der TCP bleibt stehen, während der Roboter entlang der Linearachse fährt. Show TCP coordinate system und Show base coordinate system zeichnen die Koordinatensysteme in die 3D-Ansicht. |
Kartesisches Verfahren
Die Gruppe Cartesian (TCP) zeigt die TCP-Position im gewählten Tool und in der gewählten Base (Werkzeug- und Basisdaten aus $config.dat des Roboter-Archivs). Die Schaltflächen − / + verschieben den TCP um die Step-Weite in X, Y, Z oder drehen ihn um A, B, C; ein Wert kann auch direkt eingegeben werden. Status S und Turn T der aktuellen Position werden darunter angezeigt.
Die aktuelle Position kann mit Touch up in einen Programmpunkt geschrieben werden.