Ich hatte das vor längerer Zeit mal beim Support von ABB angefragt. Da lautete die Antwort, dass das fehlende Signaldiagramm, etc. pp. zum Auto Acknowledge Input in der Doku fehlt und das entsprechend aktualisiert werden soll. Wenn die Informationen immer noch fehlen (so scheint es zu sein), dann nimm dir das Handbuch zu SafeMove für RW6. Damit sollte das dann auch für die OmniCore zu machen sein, da sich bzgl. der Funktion eigentlich nichts wesentliches geändert hat.
Posts by DS186
-
-
Du musst die Option via "Modify RobotWare" hinzufügen und danach die sys.cfg-Datei speichern, anpassen und wieder zurück auf die Steuerung laden. Dann Neustart und fertig. Müsste auch alles im genannten Handbuch zu finden sein.
-
Funktioniert auch mit OmniCore. Schau mal im Anwendungshandbuch zur Steuerungssoftware OmniCore (z.B. 3HAC066554-003) und suche nach "Auto Acknowledge Input".
-
Wenn du ein System über das FlexPendant erstellen willst, dann musst du zuerst per RobotStudio ein Installationspaket erstellen und dieses dann auf einen USB-Stick packen. Von dort aus kann man es dann mithilfe von RobotWare Installation Utilities per FlexPendant installieren.
Das wäre eine der Möglichkeiten. Schau dir mal den Integrator-Leitfaden OmniCore an, da steht alles beschrieben. Suche nach 3HAC065037-003 in der ABB Library. Eventuell brauchst du einen Premium Account, um das Dokument finden zu können.
-
Die EE-Signale kommen über das Manipulatorkabel in der Steuerung an. Von einer Änderung der Verdrahtung würde ich abraten. Über die Interconnect-Funktion (MENU > I/O > Interconnect) kannst du z.B. RIs auf DOs mappen. Alternativ kannst du das alles auch in einem BG Programm machen.
-
Man könnte eine Batterie einbauen, aber ich weiß nicht an welche Pins die ran müsste.
Der verbaute Servomotor wäre der A06B-2116-B805 (Pulsecoder Beta iA64).
Eine externe Batteriebox (direkt am Werkzeug montiert) ist durchaus üblich bei wechselbaren Servowerkzeugen. Die gibt es z.B. bei FANUC zu kaufen. Zu den Pins kann ich dir aus dem Kopf heraus leider nicht helfen. Frag am besten direkt beim FANUC Tech Support nach. Die können dir in der Angelegenheit garantiert helfen.
-
Da stimme ich dir zu. Das interpretiere ich genauso. In deinem Backup konnte ich auch nichts feststellen und mein nächster Tipp wäre ebenfalls in Richtung PLC gegangen. Wir haben auch einige Roboter mit RW 6.15.x im Feld, alle mit SafeMove Pro und akitvem CBC, aber über das Verhalten sind wir noch nie gestolpert. Habt ihr schon einen I-Start probiert und das System zurückgesetzt?
-
Welchen Wert hat der Parameter BrakeMaintenanceAlways auf den betreffenden Steuerungen?
-
Nur Sicherheit, hab ich das so richtig verstanden habe:
Ich erzeuge einen Fehler mit
RAISE ERR_SEARCHL_GI;das ruft den eigenen ErrorHandler auf
da steht wieder ein Raise um zurückzuspringenund jetzt kommt der Trick:
er sucht im Aufrufstack nach einen Errorhandler
mit ERROR (ERR_SEARCHL_GI)das muss jetzt nicht direkt die aufrufende Routine sein, das geht ggf. bis Main komplett zurück
So ist es. Per LongJump kann man im Call stack aus tief verschachtelten Aufrufen bis zur höchsten Ebene (Main) springen. Ohne LongJump müsstest du ja in deiner kompletten Aufrufstruktur, d.h. in jeder deinen Routinen, den Fehler ERR_SEARCHL_GI über die Fehlerbehandlung in die nächst höhere Routine weitergeben, bis du dort angekommen bist, wo die eigentliche Fehlerbehandlung stattfinden soll.
-
Werden IRC5-Steuerungen mittlerweile standardmäßig mit TPU4 geliefert? Oder ist der Standard weiterhin TPU3 und man muss explizit angeben, wenn man das neue FlexPendant haben möchte?
-
Komplett identisch sind die TPUs nicht. Zum Beispiel unterscheiden sich die Tastenfelder. Die Tasten vom TPU4 für IRC5 sind identisch zu denen des TPU3. Die Tasten beim TPU4 für OmniCore sind ja (teilwese) etwas anders designed.
Die Benutzeroberfläche unterscheidet sich natürlich auch (RW6 vs. RW7). Das sollten dann schon die größten und einzigen (für den Anwender sichtbaren bzw. relevanten) Unterschiede sein.
-
Seit einiger Zeit habe ich bei einer Anlage mit 9 Roboter das Problem, dass der CBC unkontrolliert startet.
Das heißt, es war nicht immer so? Was hat sich geändert, Update RW, etc.?
Hast du dir mal den Aufrufstapel zum Zeitpunkt des "unkontrollierten" CBC angeschaut? Es kann ja eigentlich kaum ohne den Aufruf der CBC-Routine passieren. Kann ich mir zumindest nur schwer vorstellen.
-
Display More
F 8 war nicht an, da anscheinend (warum auch immer) die Bedingung für Flag 8 nicht erfüllt ist.
Vorzustellen ist, das wir in Ladungsträger produzieren, die mit dem Gefache eine Einteilung haben.
z.B. nach 10 Stück hoch verschiebt dann der Roboter X oder Y um das jeweilige Stichmaß.
Deswegen auch R[11:Zaehler Box voll]=R[12:Zaehler Box X]*R[13:Zaehler Box Y]*R[14:Zaehler Box Z])
Bei R11 wird dann die gesamtstückzahl hochgerechnet und soblad 12 x 13 x 14 der gesamtstückzahl entsprechen soll F8 kommen und der DI 191 auf ON gehen.An der anderen Maschine funktioniert das mit der Abfrage auch nur hier nicht...
Und die Bedingung, d.h. der Vergleich von R[11], ist tatsächlich erfüllt? Deine Schilderung legt nämlich nahe, dass die Bedingung nicht erfüllt ist. Ersetze die Bedingung mal durch eine andere, welche definitiv erfüllt wird, R[11]=1 oder sowas in der Art.
Hast du den DO[191] mal manuell auf ON gesetzt? Dann sollte die SPS das Signal ja empfangen, wenn sonst auch alles funktioniert.
-
Wie ist der Zustand von DI[191], wenn die "Box voll" Bedingung erfüllt ist?
-
Ich habe mir deine angehängten Programme (noch) nicht angeschaut, aber:
Display More
Grundsätzlich funktioniert die Kommunikation ja auch - nur eben dieser DO 191 geht nicht aus. Also folgende Stelle:!Box voll? ;
199: IF (R[11:Zaehler Box voll]=R[12:Zaehler Box X]*R[13:Zaehler Box Y]*R[14:Zaehler Box Z]) THEN ;
200: F[8:OFF:aktuelle Box ist voll]=(ON) ;
201: DO[191:OFF:Box ist voll]=PULSE, 0.7sec ;
202: ENDIF ;
Die Zählerstände etc. passen auch aber er gibt den DO nicht aus.Geht der DO[191] nicht an oder nicht aus? Ich vermute, du meinst, dass das Signal nicht ON geschaltet wird?
Wird der Ausgang roboterseitig gesetzt und kommt bei der SPS nicht an? Oder wird der Ausgang grundsätzlich nicht gesetzt?
Wie werden die Signale zwischen Roboter und SPS übertragen (Diskrete IOs, PROFINET, etc. pp.)? Ist das SPS-Programm identisch (falls es separate Steuerungen sind)?
Wird das Flag F[8] jemals ON? Wenn ja, dann muss auch der DO[191] mindestens mal kurz ON gewesen sein. Nimm mal ein ungenutztes Flag und setze es in deiner "Box voll" Bedingung auf ON. Wenn die Bedingung erfüllt ist, dann schau die mal dein Testflag an.
-
Bei der KR C5 micro wird der Referenzschalter auf XG58 und XG33 angeschlossen.
Hast du die Referenzjustage entsprechend der SafeOperation Doku eingerichtet? Hast du mal geprüft, ob das Signal vom Referenzschalter überhaupt ankommt? Wie das zu machen ist, steht ebenfalls im Handbuch zu SafeOperation.
-
2. ein Interrupt alle 100ms ist finde ich ganzschön stramm
Ich würde das Ganze per ISignalGI lösen und nur auf die Wertänderung des GIs reagieren.
3. ich bin mir aktuell nicht sicher ob die Geschwindigkeitsänderung auf die Aktuelle bewegung angewand wird. ich glaube diese wird erst bei der nächsten Bewegungsinstruktion ausgeführt.
Die Änderung wirkt auch auf die aktuelle Bewegung. Allerdings wirkt eine Änderung per SpeedRefresh mit einer zeitlichen Verzögerung (ca. 300 bis 500 ms). Alleine schon aus diesem Grund würde ich den Interrupt nicht zyklisch alle x ms aufrufen.
-
SpeedRefresh funktioniert auf OmniCore 1:1 gleich wie auf IRC5. Das kann ich dir versichern, da selbst schon vielfach und in verschiedenen Ausführungen umgesetzt. Was funktioniert denn deiner Meinung nach nicht und wie äußert sich dein Problem? Passt der Wert von deinem GI? Kannst du mal den betreffenden Code posten?
Eine Änderung des Override über SpeedRefresh ändert nicht den Wert am FlexPendant. Mit SpeedRefresh änderst du nur einen Faktor, der zusammen mit u.a. dem FlexPendant Override den tatsächlichen Override ergibt.
-
Ich schaue nach, sobald ich zurück bin. Wird allerdings noch ein paar Tage dauern.
-
Ja, die kannst du auch wieder löschen. Im EA-Konfigurator unter RW6 kannst du die Dateien im entsprechenden Pfad einfach löschen. Ich bin aber aktuell unterwegs und kann dir das richtige Verzeichnis nicht suchen. Auswendig weiß ich es leider auch nicht.
Im EA-Konfigurator unter RW7 sind die GSDML-Dateien Teil eines EA-Projekts (soweit ich weiß). Mit einem neuen EA-Projekt solltest du hier also wieder sauber sein. Bin mir aber gerade nicht ganz sicher.
