Hallo Niem,
ich hatte Kontakt mit iPhysics von machineering, mit der Software kann man auf alle Fälle UR simulieren + andere Anlagenteile (Linearachsen,...). Die Simulation kann auch als Dienstleistung an machineering selbst vergeben werden (auf Basis von CAD-Daten).
In meinem Fall kam es aber nicht zur Zusammenarbeit, konnten uns dann doch ohne Simulation helfen.
Grüße,
Tobi
Hallo zusammen,
danke für die Antworten! Ich werde mir Fastsuite und iPhysics ansehen 
Viele Grüße,
Tobias Obermeier
Hallo zusammen,
ich suche nach einer leistungsfähigen Simulationssoftware für Universal Robots. Die Software sollte mehrere Roboter gleichzeitig simulieren können und auch große CAD-Daten verarbeiten können ggf. auch die Simulation von Zylindern, Bänder übernehmen.
Nutzt jemand erfolgreich eine Simulationssoftware die er empfehlen kann?
Danke und Grüße,
Tobias Obermeier
Hallo JDab,
meines Wissens nach gibt es hier keine Möglichkeit.
Viele Grüße,
Tobi
Hallo Simon Frank,
Hendrik hat recht. Die Berührungsempfindlichkeit des gesamten Roboterarms wird über die Roboterlimits unter Installation/Sicherheit/Roboterlimits eingestellt.
Alle Berührungen die ab Tool-Flange erfolgen, kann der Kraftmomentensensor in der 6. Achse detektieren. Aber Vorsicht: Der Kraftmomentensensor ist keine "Sicherheitsfunktion" des Roboters, erkennt also die Berührungen mit einer Person nicht sicher (nicht zweikanalig etc.). Den Kraftmomentensensor darfst du also nur für die Detektion von Prozesskräften (Fügen etc.) heranziehen.
Für die Bewertung, ob deinen Applikation "kollaborationstauglich" ist, musst du die Kraft- und Druckwerte messen, die vom Roboter ausgehen. Die sind immer individuell und werden eben unter Anderem durch die Einstellungen in den Roboterlimits beeinflusst.
Viele Grüße,
Tobi
Hallo Hendrik,
ich glaube ich kenne dein Problem. Wenn man Unterprogramme beim UR verwendet, und dann das Hauptprogramm lädt (mit all seinen Unterprogrammen) kommt für jede Variable die im Haupt und Unterprogramm existiert die Meldung ob diese automatisch umbenannt werden soll.
Du kannst die Fehlermeldung folgendermaßen vermeiden:
Nimm den Haken (gelbe Markierung unten) weg. Das hat zur Folge dass die Fehlermeldung nicht mehr erscheint. Wenn du im Unterprogramm aber etwas änderst musst du für das Abspeichern den Haken setzen, damit das Unterprogramm aktualisiert wird. Danach kannst du ihn wieder wegnehmen.
Gib uns gerne Feedback, ob das für dich funktioniert.
Hallo Hendrik,
du definierst deine Ebene ja über den Assistenten, in dem du drei Punkte angibst. Je nachdem wie du die positive Y-Achse angibst, definiert sich auch deine positive Z-Achse und damit die Seite auf der der Roboter arbeiten darf.
Versuche mal Punkt 3 so anzugeben wie in meiner Abbildung "hingeschmiert"....
Gib gerne Rückmeldung, ob das funktioniert hat!
Grüße,
Tobi
Hallo Martl,
gib uns gerne hier Rückmeldung, wie du die Sache für dich gelöst hast. Ich kenne deine Anwendung nicht, aber in einer Laboranwendung für eine schnelle Machbarkeitsuntersuchung lasse ich dann unter Installation/Safety/IO die Betriebsart raus und verwende keinen Zustimmtaster. Hängt natürlich von den Umständen ab, ob ich das für mich als "sicher" vertreten kann...
Wenn du dann noch einfacher im Freedrive-Modus teachen möchtest und dir die Hände ausgehen, habe ich einen Tipp aus Eigenentwicklung für dich: https://www.obermeier-systems.de/Products/TeachRing
Viele Grüße aus und nach Landshut,
Tobi
Hallo moucio,
du kannst die beiden Roboter für den Anfang relativ simpel gegeneinander mit IO-Signalen verriegeln.
Beispiel:
Ausgang 1 des UR10 verdrahtest du auf Eingang 1 des UR3, Ausgang 1 des UR3 verdrahtest du auf Eingang 1 des UR10.
Der UR3 muss dann für seine Einfahrt in den gemeinsamen Arbeitsraum auf den Eingang 1 = "high" "warten". Solange der UR3 im gemeinsamen Arbeitsraum ist, setzt er Ausgang 1 = "low". Nach Verlassen des Arbeitsraums setzt der UR3 den Ausgang 1 = "low" und der UR10 kann einfahren. Für den UR10 musst du das ebenso umsetzen.
In der Programmierung des UR kannst du dafür die Befehle Set/Einstellen.. und Wait/Warten.. verwenden.
Du solltest unbedingt die Freigabesignale für die Einfahrt in den gemeinsamen Arbeitsraum auf "high" abfragen, damit z. B. ein Drahtbruch erkannt wird und deine Roboter nicht Crashen.
Viel Erfolg beim Test!
Tobi
Hallo zusammen,
für die Überwachung der Schutztüre kann ein Sicherheitstürschalter (von z. B. Schmersal, Pilz, Euchner,...) am UR angeschlossen werden. Siehe Bild im Anhang aus der Bedienungsanleitung.
Um den Roboter bei offener Schutztüre teachen etc. zu können ist auch beim UR ein Zustimmtaster/3-Stufenschalter nötig.
Möglichkeit 1: Es gibt inzwischen die UR-Teachpanel auch mit 3-Stufenschalter. Diese können nachgerüstet werden: https://www.universal-robots.c…ach-pendant-for-e-series/
Möglichkeit 2: Es kann ein "externer" 3-Stufenschalter am UR angeschlossen werden. Der von Omron bietet z. B. zwei zusätzliche Tasten, auf die z. B. der Freedrive gelegt werden könnte. https://industrial.omron.de/de/products/a4eg
Viele Grüße,
Tobi
Hallo Simon,
du kannst per FTP Daten und Programme zum Roboter übertragen. Ich nutze dafür die Software "FileZilla". Wenn du also beispielsweise im Simulator offline Programme erstellst, musst du nur per Netzwerk Zugriff auf den UR haben und kannst direkt Programme oder Installationsdateien auf den Roboter schieben bzw. Sicherungen vom Roboter ziehen.
Wenn du das suchst, könnte ich dir noch genauere Infos geben. Spontan habe ich im englischen Forum diesen Eintrag dazu gefunden:
https://www.robot-forum.com/ro…nection-to-ur-controller/
Viele Grüße,
Tobi
Hallo Jan,
ich kann dir nicht direkt weiterhelfen, aber die Support-Seite von UR empfehlen. Hier gibt es verschiedene Artikel zur Anbindung des UR´s an Steuerungen: https://www.universal-robots.c…view&filters=&categoryId=
Vielleicht wirst du dort fündig...
Grüße,
Tobi
Hallo zusammen,
danke für Eure Meinungen und den Input zum Thema Sonderlackierungen. Gerade die Hinweise zur farblichen Kennzeichnung bewegter Teile (somit Roboter) teile ich auch.
Vielleicht zur Erklärung, warum wir bei uns durchaus einen Sinn für eine Sonderlackierung von Robotern sehen: Wichtige Kunden und Partner werden durch Werke geführt, um sie eben nicht nur von der Qualität der eigenen Produkte zu überzeugen, sondern auch mit einer professionellen, qualitativ hochwertigen und sauberen Produktion zu überzeugen. Der optische Eindruck ist hier wichtig und lässt oft auf nicht sichtbare "Qualitäten" einer Produktion schließen! Ich gebe Euch natürlich damit recht, dass eine Sonderlackierung (ggf. zur optischen Standardisierung verschiedener Roboterhersteller) teuer ist und keinen unmittelbaren Mehrwert bietet.
Für Mitgliedern die ggf. auch auf der Suche nach Anregung und Diskussion zum Thema Sonderlackierung von Industrierobotern sind, möchte ich hier noch die Ergebnisse meiner bisherigen Recherche teilen. Ich freue mich, wenn auch andere Mitglieder noch Bilder und Meinungen von nicht nur technisch, sondern auch optisch, tollen Anlagen teilen möchten.
Viele Grüße,
Tobi
Zum Schluss aber noch ein echter Aprilscherz:
Hallo zusammen,
ich bin im Bereich Robotik in einem Unternehmen mit zwei Produktionswerken in Deutschland tätig. Wir arbeiten aktuell an einem neuen Roboterstandard und wollen auch die Lackierung definieren. Hierzu bin ich noch auf der Suche nach Inspiration. Habt ihr schon Roboter in speziellen RAL-Farbtönen gesehen, die euch besonders gut gefallen haben? Könnt ihr Farben empfehlen? Habt ihr vielleicht auch Fotos von Roboter in Sonderlackierungen? Gegoogelt habe ich schon genug ;-).
Grüße,
Tobi
Hallo Hendrik,
ich habe noch keinen UR oder anderen Roboter in direkter Mensch-Roboter-Kollaboration eingesetzt und würde das auch nur tun, wenn es nicht anders geht.
Grund: Die Kraft- und Druckgrenzwerte zu messen ist aufwändig, die Robotergeschwindigkeiten müssen meist gering sein, damit die Grenzwerte eingehalten werden können, die kollaborationsgerechte Gestaltung der Roboterperipherie ist schwierig,.... Diese Gründe machen eine Mensch-Roboter-Kollaboration letztendlich meist unwirtschaftlich.
Es gibt meines Wissens nach keine echten Alternative zu Messungen. Sicher, die Grenzwerte werden durch die Norm bzw. technische Spezifikation (TS15066) vorgegeben - was kein Gesetz ist. Du kannst die "Sicherheit" deiner Anwendung auch auf anderem Wege beweisen, aber das ist vermutlich noch aufwändiger.
Wenn es eine Kollaboration sein soll:
- Verhindere eine mögliche Kollision oberhalb von Hals und Kopf des Menschen
- Nutze die virtuellen Wände des Roboters um dessen Bewegungsbereich sicher einzuschränken, quetschende (quasistatische) Kollisionen möglichst auszuschließen und wenigst mögliche Kollisionsbereiche zu erreichen, die gemessen werden "müssen"
- Versuche die Wahrscheinlichkeit einer Kollision zu reduzieren, indem Mensch und Roboter im vorgesehenen Anwendungsfall nur wenig Zeit im gemeinsamen Arbeitsraum verbringen
Gerne freue ich mich auch über die Diskussion mit anderen Mitgliedern!
Grüße,
Tobi
Hallo Hendrik,
ich kann dein Problem nachvollziehen. Wenn z. B. eine 2D-Kamera die Koordinaten eines Bauteils ermittelt und der Roboter dieses entsprechend der Orientierung picken soll, plant der Roboter nach meinem Verständnis seine Bahn so, dass er die gegebenen Orientierung schnellstmöglich mit möglichst wenig Achsbewegung erreicht. Damit kannst du erstmal nicht beeinflussen, ob +90° oder -270° gedreht wird. Ich habe mir dabei immer folgendermaßen geholfen:
1) Die Kabel am Tool müssen eine Drehung um +-180° oder etwas mehr erlauben
2) Achsbegrenzungen einstellen (Installation>Gelenkgrenzen) z. B. +- 185°
3) Den Roboter an der letzten geteachten Position vor der Berechnung "günstig" positionieren (Rotation um Z ungefähr 0°)
Zu 3): Wenn der Roboter an der Position, von wo er die berechnete Position anfährt, in rz bei ca. 0° steht, wird er einen berechneten Punkt mit einer Drehung um +90° anstatt -270° anfahren. +90° ist nämlich der schnellere Weg.
Ich hoffe das hilft dir weiter. Vielleicht hat ein anderes Forumsmitglied das Problem auch schon auf einen andere Weise gelöst und schlaut uns beide auf.
Viele Grüße,
Tobi
Hallo Hendrik,
prinzipiell geht das mit dem Scriptbefehl "set_tcp()". Du musst für den TCP hier eine Pose angeben und auf diese Pose kannst du z. B. eine Variable draufrechnen. Siehe Beispiel im Anhang.
Grundsätzlich würde ich aber eher deinen Greifer überarbeiten. Mit einem Greifer, der sich verformt wirst du auf Dauer nicht glücklich 
.
Viele Grüße,
Tobi
Hallo JDab,
wenn der Not-Halt Schalter am Roboter angeschlossen ist und unter Installation/Sicherheit/EA richtig konfiguriert ist, wird bei Betätigung dein Roboterprogramm stoppen und keine Befehle zur Ansteuerung der Ampel mehr ausführen.
Bietet dein Not-Halt Schalter keine Hilfskontakte, über die du bei Betätigung die rote LED an der Ampel direkt beschalten kannst? Wäre das nicht das Einfachste? Bin hier auch gespannt auf die Meinung Anderer...
Grüße,
Tobi
Hallo Bastian,
ich versuche mal dir zu helfen. Wie du schon angeschnitten hast, kannst du die Anwendung gut mit einer kurzen Script-Zeile umsetzen. Füge diese über Program/Advanced/Script in dein Programm ein. Für die lineare Bewegung nutzt du den Scriptbefehl "movel". Der ist im Script Manual auf Seite 28 bzw. Screenshot "movel" im Anhang beschrieben.
Leider kannst du die gewünschten Positionswerte für den movel-Befehl nicht wie gewohnt teachen, sondern musst diese eintippen. Wenn du den Roboter in eine bestimmte Position bringst, kannst du die aktuellen Werte aber ablesen (Screenshot "Werte der aktuellen Roboterposition") und in den Scriptbefehl eintragen. Deine Variable nenne ich für das Beispiel "Hoehe"
Im Befehl "movel" gibst du nun also die Pose (X,Y,Z,rx,ry,rz) an, auf die du die "Hoehe" addieren möchtest (vermutlich auf die Z-Koordinate). Die Hohe muss dabei aber noch durch 1000 geteilt werden, da eine Pose in der Einheit Meter (XYZ) und rad (rxryrz) definiert wird. Bsp: Hoehe=100mm/1000=0,1m. Gesamter Befehl: siehe Screenshot "scriptzeile".
Mit dem Befehl movel/movej kannst du auf deine Startposition fahren, mit einem zweiten movel dann auf deine Endposition. So kannst du beide Positionen in Z abhängig von "Hoehe" machen.
Ich hoffe das hilft dir weiter. Falls dir der Roboter einen Fehler zu meinem Scriptbefehl ausgibt, kontrolliere die genaue Syntax nochmal anhand des Script Manuals.
Viel Erfolg
Hallo Hendrik,
hier gibt es einen Artikel auf UR Suport dazu: https://www.universal-robots.c…cles/ur/seek-using-force/
Leider ist der Artikel für die CB-Serie geschrieben. Wenn ich mich richtig erinnere, sind die Parameter, die du zur Verfügung hast, die selben:
- Die Kraft mit der du suchst
- Die Geschwindigkeit, mit der du fährst während du suchst (würde ich möglichst gering halten)
- Die negative Beschleunigung, wie schnell du stoppst, sobald der Kraftgrenzwert erreicht ist (würde ich hoch einstellen, damit der Roboter schnell stoppt und dein Rohr nicht verbiegt)
Es wird auch empfohlen, die Kraftwerte des FT-Sensors zu "nullen" bevor du mit der kraftbasierten Suche beginnst. Dazu den Script-Befehl "zero_ftsensor()" vor dem Kraftbefehl einfügen. Beschrieben ist das auch nochmal hier auf Seite 22 unten: https://s3-eu-west-1.amazonaws…scriptManual_e-Series.pdf
Ich hoffe ich konnte dir weiterhelfen.
Grüße,
Tobi
