Posts by DS186

    Das von dir beschriebene Verhalten kommt mir bekannt vor. Wir verwenden allerdings auf allen unseren Roboter die Option Remote iPendant (R843). Ich schicke dir mal eine private Nachricht mit einem Dokument. Vielleicht hilft dir das weiter.

    Im übrigen sieht die Oberfläche bei mir so aus (Zugriff via Chrome und R843 auf der Steuerung vorhanden):

    Dann probiere ich mal Chrome auf dem Linux-Rechner, auch wenn der FANUC-Support davon abgeraten hat.

    Wovon abgeraten? Von Chrome in Verbindung mit Linux? Oder von Chrome im Allgemeinen? Ich verwende immer Chrome für den Zugriff. Habe damit keinerlei Probleme. Zudem ist Chrome eine offizielle Empfehlung von FANUC. Chrome (ab V31) oder IE 11, siehe Handbuch Grundlegende Bedienvorgänge.

    Was meinst du mit abgewählter SPS? Den Submit-Interpreter SPS.sub? Der hat mit $MOVE_ENABLE nichts zu tun. Und falls dein $MOVE_ENABLE von einer übergeordneten PLC kommt und du die Verbindung zur PLC trennen würdest, dann könnte es auch nicht funktionieren, da die Fahrfreigabe via $MOVE_ENABLE FALSE wäre.

    Das mit deinem Roboter-Interpreter hat mit dem Handverfahren in T1 nichts zu tun. Daher würde ich das erstmal außen vor lassen. Du kannst aber gerne mal das betreffende Programm sowie die von dir beschriebene Meldung posten.

    Zu der T1-Geschichte:

    In welcher Betriebsart soll der Roboter denn am Ende laufen? AUT oder EXT? Du hast bisher von beiden Betriebsarten geschrieben. Ich bin bisher davon ausgegangen, dass eine übergeordnete Steuerung im Spiel ist, da oben von "Schnittstellenprogrammierer" die Rede ist. D.h. hängt der Roboter an einer SPS, werden nur ein paar Taster oder das smartPAD verwendet?

    Ich werde also die XG58 Thematik überprüfen, falls nötig nochmal Dummy Stecker drauf und das Verhalten von $move_enable in T1 mit gedrückter Zustimmtaste.

    Mit aktivem Inbetriebnahme-Modus kannst du den Roboter in T1 verfahren? Was meinst du mit Dummy-Stecker? Brückenstecker für die sicheren Signale auf XG11.1 und XG58? Wenn das Ganze ohne weitere Änderungen mit deinem Dummy-Stecker funktioniert, dann liegt wohl da der Hund begraben.

    Du hast $MOVE_ENABLE auf einen anderen Eingang konfiguriert?! Von wem oder was wird der Eingang gesteuert? Du könntest $MOVE_ENABLE tesweise zurück auf $IN[1025] konfigurieren und dann versuchen, ob sich der Roboter in T1 verfahren lässt.

    Und nur damit ich nichts falsch verstehe.. wenn ich die SPS abwähle, also "S" kasten oben auf Grau.. müsste es dann nicht wieder funktionieren? Das habe ich heute als letztes probiert, hat allerdings leider auch keine Abhilfe verschafft.

    Nein, den oder die Submit-Interpreter kannst du laufen lassen. Ich meinte mit dem SPSler eigentlich den SPS-Programmierer der übergeordneten Steuerung (falls vorhanden).

    Wenn alles nichts hilft, dann helfen (uns) unter Umständen ein paar Bilder.

    Wie sieht es mit dem XG58-Stecker aus? Ist der gebrückt oder ist eine externe Zustimmung angeschlossen?

    Prüfe bitte mal den Zustand von $MOVE_ENABLE in T1 und mit gedrückter Zustimmung. Vielleicht nimmt dein SPSler dir das $MOVE_ENABLE weg. Die Konfiguration weg von $IN[1025] ist korrekt, muss ohnehin gemacht werden.

    Dein "Wait for VARIABLE" ist wohl eine andere Baustelle. Oder versuchst du, eben dieses Programm in T1 zu fahren und es tut sich dann an dieser nichts? Der Status Rot des Roboter-Interpreters bedeutet nur, dass ein gestartetes Programm angehalten wurde.

    Du hast dich auf dem Kuka auch angemeldet?

    Guter Punkt. Zum Handverfahren braucht der aktive Benutzer die die Rechte "Handverfahren mit den Verfahrtasten". Sollte standardmäßig aber eigentlich gegeben sein.

    Du schreibst von Abstimmung mit dem Schnittstellenprogrammierer. Hast du in der Zwischenzeit zufällig die Konfig von $MOVE_ENABLE geändert?

    KR C5 oder KR C5 micro? Hat die Steuerung eine diskrete Sicherheitsschnittstelle? Wenn ja, ist hier alles korrekt verdrahtet? Oder hast du z.B. PROFIsafe für den Austausch der sicheren Signale? Hat sich der Roboter überhaupt schonmal in T1 bewegen lassen? Wenn ja, was hat sich seither geändert? Lässt sich der Roboter bewegen, wenn du den Inbetriebnahme-Modus aktivierst? Stehen wirklich überhaupt keine Meldungen an, auch nicht in der Historie?

    Kann man tun, das ist dann aber tatsächlich mehr als "unglücklich". Man kann die Zeit bis zum Timeout aber auch mit der Systemvariable $WAITTMOUT im Ablauf variabel beschreiben.

    Ich habe dazu ein kleines Programm erstellt. Das kannst du z.B. vor einem Timeout LBL aufrufen, wenn du die Zeit ändern möchtest.

    Wie ist das mit den Safety-Signalen beim Fanuc? Sind die wie beim KUKA festgelegt? Gibt es eine Übersicht?

    Ich habe bisher keine Übersicht gefunden.

    Es gibt eine Reihe interner Signale, welche fest zugeordnet sind. Man kann aber die zur Verfügung stehenden Signale (nahezu) beliebig logisch verknüpfen und frei auf die Schnittstelle legen. Eine Übersicht findest du im DCS-Handbuch.

    Wie wird das mit den sicheren Werkzeugen gehandhabt, wie bei KUKA?

    Im Vergleich zu KUKA stehen z.B. verschiedene geometrische Formen zur Erstellung eines sicheren Werkzeugs zur Verfügung (nicht nur Kugeln). Tool change und weitere Fuktionen gibt es natürlich auch.

    Schau dir am besten zuerst mal das Handbuch zu DCS an (z.B. B-83184GE/12). Dort findest du alle wesentlichen Informationen.

    Damit wir uns richtig verstehen: Du möchtest auf einen DI (oder ein anderes Ereignis) warten und wenn der DI nach einer bestimmten Zeit nicht den gewünschten Zustand annimmt, dann möchtest du einen DO setzen?

    Du kannst dafür ein WAIT TIMEOUT nehmen. Da gibt es zwar auch ein LBL, zu dem man im Falle eines Timeouts springt, aber das Ganze ist recht elegant (für einen FANUC). Das wäre so ganz grob vergleichbar mit deiner ABB-Lösung.

    Alternativ könntest du das mit Hilfe eines BG Logic Tasks machen. Also in etwa so wie deine KUKA-Lösung mit dem Submit.

    Ich kann keine Pro- und Contra-Liste bieten, wohl aber eine leidvolle Erfahrung. Wir hatten mal einen CR-7iA von FANUC auf einer Messe im Einsatz. Unser Stand war direkt an einem Hallentor und draußen war es relativ kalt. Wenn das Tor offen stand, dann ging bei dem Kollegen gar nichts, weil ständig ein Fehler mit dem Kraftsensor da war. Es hat sich herausgestellt, dass durch den Unterschied zwischen warmer Halle und kalter Zugluft der Kraftsensor nicht richtig funktioniert hat. Es gab somit ständig Fehlauslösungen. Mit Tor zu und einer gewissen Aufwärmphase lief die Kiste dann so einigermaßen.

    Das ganze Marketing rund um die Cobots von wegen einfacher Programmierung, etc. pp. sind die reinste Täuschung, klingt aber für unerfahrene Anwender ziemlich verlockend. Die scheinbar so einfache Programmierung über irgendwelche Wizards sind bis zu einem gewissen Punkt bestimmt einfach und toll, aber die Lösung am Ende (meistens) alles, aber nicht im Ansatz industrietauglich.

    Auch eine ordentliche Risikobewertung für eine Cobot-Anwendung ist nicht auf die leichte Schulter zu nehmen.

    Meine Meinung: Lass die Finger weg von einem Cobot. Und wenn einer meint, er muss das unbedingt haben, dann stell dich auf die Hinterfüße.