Im Systemfehlerfall sollte Schreibzugriff eigentlich direkt da sein. System über den Installationsmanager neu aufsetzen würde ich versuchen. Dazu ist aber sicher ein altes Backup nötig! Ansonsten mal mir ABB telefonieren!
Beiträge von AtoK09
-
-
Je nach Steuerungsstand evtl. im Vorfeld Maus und Tastatur anklemmen bei PS/2 Anschlüssen, USB kann jederzeit angesteckt werden. Die Bedienung über die Tastatur des KCP's ist recht tricky...
Edit: Natürlich muss die Steuerung neu gestartet werden bevor PS/2 Anschlüsse registriert werden und verwendet werden können!
-
Leider kann ich nichts erkennen was wie ein Gummiball springt. Was passiert denn wenn du das Programm Zeilenweise abarbeitest? Wie verhält sich der Robi wenn du ohne Überschleifen fährst?
Ich würde (unter anderem wegen der Übersichtlichkeit) mir eine POS-Variable erstellen welche ich mit der POS aus dem Array beschreibe, diese würde ich in meine LIN abfahren (nach jeder abgefahrenen POS würde ich dann eine nicht erreichbare POS in die Variable schreiben), so kann ich zumindest zu jedem Zeitpunkt auch klar rauslesen wohin der Robi möchte. Dann würde ich ohne Überschleifen das Programm Zeilenweise abfahren und beobachten. Hier sollte dann doch auch zu erkennen sein was in deinem .src vorgeht.
Edit sagt: Hab den "Gumiball-Zähler" dann doch noch erkannt. Unter realen Bedingungen würde ich sagen das ist die Trägheit des Bildschirms. Auch dein Programmzeiger sagt eindeutig ich bin zu schnell für deinen Monitor. Deshalb einmal versuchen ohne Überschleifen und im "Automatik-Ablauf" auch ruhig mal ohne Vorlauf abarbeiten!
-
Am Schweißnahtanfang und am Ende sollte schon ein fine-Punkt stehen!
-
Ich stehe nun mit ABB in Kontakt dazu, habe noch ein zweites System bei welchem die selben Fehler auftreten und ich erwarte noch weitere...
-
Danke für deine Antwort, in diesem Fall haben wir die Schlüssellose Option, "735-7 Keyless Mode Switch, 3 modes".
-
Hallo zusammen, ich habe eine neue Anlage mit IRB2600, RW 6.10.00, nach einem Neustart des Systems erhalte ich drei Fehler, die ich so noch nie gesehen habe. Könnt ihr/ kann jmd. dazu etwas sagen?
Alle Leitungen habe ich Kontrolliert, scheinen iO. Steuerung wurde mehrfach neu gestartet. Für eure Hilfe bedanke ich mich im voraus!
-
Why you use two threads? It's difficult to reply seriously to two topics.
-
-
Ich werde nicht viel zur Lösung mit meinem Einwurf beitragen, und ich weiß keiner mag Besserwisser. Doch ein sauber geschriebenes Programm hilft mir zumindest um diverse Problemstellungen zu Lösen. Signalworte werden bei KUKA groß geschrieben und Einrücken hilft sehr bei der Lesbarkeit des Programms.
Ansonsten hat Hermann ja schon angedeutet, Zeit für die Ablage stoppen und hinterher (nach Lage eins) zusammenzählen. Feldvariable ist ein Array? Wenn dem so ist, ein eindimensionales Array mit x Feldern anlegen, wobei x die Anzahl der Ablageplätze der ersten Ebene ist. Nach jedem Durchgang die Zeit in das jeweilige Feld schreiben und am Ende die Felder addieren, ggfs. durch 6000 teilen um auf Minuten zu kommen.
-
Er springt eben mit "RESUME" NICHT wieder in das UP...sondern in das Hauptprogramm, weil er dort deklariert wurde - oder ich versteh was komplett falsch.
Du hast recht... deshalb Deklariere ich meine Interrupts auch für/ in diversen UP'S. Sorry für die Fehlinformation.
-
Mit dem "RESUME" setzt du das Programm an der Stelle fort, an der der Interrupt ausgelöst hat: du brichst ab, der Bediener greift ein, drückt "wiederholen", POS_RET positioniert den Robbie an die "richtige" Stelle und jetzt möchtest du dein Programm doch wieder in deinem UP weiter abarbeiten!
Edith sagt: Deklaration des Interrupt im Hauptprogramm, auslösen des Interrupt im Unterprogramm. Der PZ springt in die Interruptroutine macht dann so Interruptdinge und springt mit "RESUME" wieder in das UP wo der Interrupt ausgelöst wurde.
-
Bedeutet, nach , bzw. vor POS_RET wird die Situation gerade gerückt, dann ist ja alles gut! Weiter im Text, dann doch mit RESUME.
-
...Allerdings ist mir nicht klar, wie man nach einer Kollision ohne weiteres Zutun einfach wieder auf die selbe Position fahren kann, und die Kollision dann nicht mehr auftreten soll?!
Hier gehe ich mit! Du brichst die Bewegung durch Interrupt, "BRAKE F" ab, um dann mit PTP $POS_RET wieder auf den Kollisionspunkt zu fahren? Warum?
-
Ich verstehe das so, dass der Robi wieder auf die Position vor dem Interrupt zurück fährt... ansonsten bin ich da leider raus. Ich breche Bewegungen wie oben beschrieben ab und fahre dann nach einem "RESUME" mit einer andern Bewegung weiter. Sry...
Edith sagt: Ansonsten schreib dir mal 'nen Stop, bzw "HALT" in den Interrupt um dann im SingleStep die Zeilen einzeln zu bearbeiten, um zu sehen wann der Robi was macht...
-
Hast du versucht die vorhergehende Bewegung im Interrupt abzubrechen? In einem Suchprogramm breche ich die Bewegung mit
CodeINTERRUPT OFF 1 BRAKE F WAIT SEC 0.5ab.
-
-
-
Nein, einfach weglassen heißt, nicht mit einer "E6POS" fahren sondern "FRAME" benutzen (DECL FRAME pName....). Dabei musst du aber bedenken, dass Punkte eben auch mit verschiedenen Achskonfigurationen erreicht werden können (um die Achskonfiguration eindeutig zu machen benutzt man E6POS und eben S und T), auch ist dass durchfahren von Singularitäten damit möglich, bzw nicht verhindert...
-
Doch man findet das in der Doku... kann es aber grad nicht raus suchen. Diese Werte bestimmen eindeutig die Achsposition signifikanter Achsen. Ich meine A1,A4,A6 plus evtl. Zusatzachsen
