Beiträge von maddin

Hallo,

vielen Dank für die Antwort, hat sich erledigt.
An anderen Robotern kann ich ohne Probleme mit denselben Einstellungen arbeiten.

Warscheinlich liegt es an der Roboter- Netzwerkkarte.

Das Problem war, daß ich ein neues Laptop bekommen hatte und erst kurz zuvor alles installiert habe.
Daher war ich nicht sicher ob es evtl. an den Programmeinstellungen liegt.

Gruß Maddin

Hallo zusammen,

ich steh gerade ein bißchen auf dem Schlauch.....

Ich benutze WS_FTP, um von S4C+ Steuerungen Dateien hoch- und runterzuladen.

Heute hatte ich Riesenprobleme an einem Roboter beim Herunterziehen von Programmmodulen.
Die Dateien sind nicht sonderlich groß (ca. 80 kB pro Datei), aber der Download war so lahm, das kann nicht normal sein.
Ich bin an der Service-Dose (10 MBit/s) angedockt, und in der Fortschrittsanzeige des FTP-Programmes scheint der Download mal für 1 min stillzustehen, nichts tut sich, unabhängig ob der Roboter läuft oder nicht.

Zu allem Überfluß hatte ich zweimal eine unvollständige Datei auf meinem Laptop, obwohl kein Transferfehler gemeldet wurde.
Hab dann doch knurrend zur Diskette gegriffen :eviltongue:

Anschließend habe ich versucht, über Ultra-Edit (FTP Datei öffnen) zuzugreifen, da hatte ich daselbe Problem. Es dauert furchtbar lange, bis die Datei geöffnet wird.

Ich denke, daß die Verbindung in Ordnung ist, sonst würde der Inhalt der hD0a: nicht angezeigt.
Was muß man denn an den Einstellungen der FTP-Programme noch alles beachten ?

Habt Ihr einen Tipp ??

Gruß maddin

Hallo AbFaKuMo,

da du ja schon in einer Schleife bist, kannst du deinen TPRead-Screen ganz einfach refreshen, indem du den Zusatz "\MaxTime" dazunimmst.

Nach Ablauf dieser MaxTime ohne Aktion der Function-Keys wird das TPRead übersprungen. Damit die Fehlerbehandlung nicht aufgerufen wird, mußt du den Zusatz "\BreakFlag" auch mit verwenden.
Du mußt dazu eine errnum definieren (global), in die dann das System den Fehler "ERR_TP_MAXTIME" schreiben kann.
Beispiel:

Zitat

VAR errnum errnoMaxtime:=0;

Deine TPReadFK Zeile sieht dann so aus:

Zitat

TPReadFK nFK2,""," erneut pruefen ","Abfrage ignorieren",""," ja "," nein "\MaxTime:=3\BreakFlag:=errnoMaxtime;

Damit überspringt das Programm nach 3 Sekunden ohne Eingabe die Zeile und arbeitet das Programm weiter ab. Da ja die Variable nFK2 nicht beschrieben wurde, beginnt die While Schleife von vorne und der gesamte Screen wird nochmals beschrieben.
Damit hast du auf jeden Fall immer, auch nach Stop o.ä. nach 3 Sekunden den kompletten Screen wieder auf dem Panel.

Auf jeden Fall die Variable "nFK2" vor Eintritt in die While Schleife initialisieren.

Zitat

nFK2:=0;

Probiers mal aus....

Gruß Maddin

\MaxTime:=7\BreakFlag:=errnoMaxtime;

Hi Paul,

when we want to delete a damaged system on our S4C controllers, we switch off the cabinet and disconnect the 2 battery cells above the computer rack for a few seconds.

The second way is to switch off the cabinet and disconnect all the cards in the computer rack for a few seconds, then put them back in the rack again.

maybe this will help you with your problem....

You can connect to every card with Hyperterminal, but i dont now how to do any action on the cards.....

Regards
Maddin

Hallo ,

@ ErikPa:

Es besteht ja kein Problem mit dem Roboter, mich hat nur die Syntax interessiert. Die Gelegenheit zur Aufklärung bietet sich mit Sicherheit in nächster Zeit.
Der ABB Techniker hat noch diverse Arbeiten zu erledigen und kommt mit Sicherheit bald ins Haus.
Dann spreche ich ihn darauf an.

In diesem Sinne... Vielen Dank an alle für all die Infos.

Gruß Maddin

Hallo zusammen,

ABB selber hat das Programm zusammengeschustert.

Der Roboter ist einem Pickmaster untergeordnet, der ihn mit Positionsdaten versorgt.

Vom Pickmaster gibt es für den Roboter fertige Programmodule. In denen ist die Syntax zu finden, wegen der ich gepostet habe.
Die eigentliche Programmschleife findet in einem Unterprogramm statt, daß mit der Teilenummer benannt ist.
Der Roboter durchläuft aber vorher noch andere Routinen (Homepositionscheck, Initialisierung usw.), was auch wunderbar funktioniert. Diese Routinen sind in verschiedene Systemmodule verteilt. Und mir fehlt eben diese Bindung. Ich weiß im Endeffekt nicht welche Routine durch diese Sytnax aufgerufen wird.

Ich versuche mal in aller Ruhe über das Teachpanel was rauszufinden.

Bis denne

P.S. Der ABB Techniker, welcher den Roboter inbetriebgenommen hat, war über das verschlüsselte Systemmodul auch sehr begeistert...

Gruß Maddin

Hallo zusammen,

vielen Dank für eure Antworten.

Ihr habt sicher recht mit dem Routinenaufruf
(es sollte ein Unterprogramm-Aufruf geschehen anhand einer Teilenummer).

Leider finde ich weder die Deklaration (String) noch eine Zuweisung im gesamten Backup.
Es gibt allerdings ein verschlüsseltes Systemmodul, das für mich nicht einsehbar ist.

Mit Sicherheit steht das Zeug da drin .......

Bis denne

Gruß Maddin

Hallo Experten,

wir haben einen Roboter mit einer IRC5 Steuerung in Betrieb seit kurzem.

Bei der Programmdurchsicht bin ich auf folgende Programmzeile gestossen:

%RoutineName%;

Diese Syntax ist mir bis dato unbekannt, ist dies doch unsere 1. IRC5 Steuerung.

In der Dokumentation steht, daß mit diesem Befehl eine Routine oder Modul geladen werden kann, allerdings in Verbindung mit einem Ladebefehl.

Einen Ladebefehl habe ich nirgends gefunden.

Der Name macht mir auch zu schaffen.....
"RoutineName" taucht weder als Variable, Routine oder Modul im gesamten Backup auf.

Habt ihr eine Idee was hier geschieht ??

Bin mal gespannt

Gruß Maddin

hallo Paulino,

hatte den Fehler an sich noch nie...

aber an deiner Stelle würde ich die Resolverleitung prüfen vom SMB zu Achse 6. Mir kommt das vor wie ein sporadischer Kabelbruch, der während der Bewegung passiert.

Viel Glück

Gruß Maddin

Hallo zusammen,

der Roboter hat einen massiven Getriebeschaden in Achse 2 .

Wir haben ihn außer Betrieb genommen. In den letzten paar Tagen hat sich die Achse 2 auch noch akustisch bemerkbar gemacht.

Ein Wunder, daß der Roboter so lange durchgehalten hat.

Gruß Maddin

Hallo zusammen,

Dodo:

Du musst bei ULTRAEDIT vorsichtig sein, wenn du nach dem Editieren speichern willst.

Bei "speichern unter" kannst du als Dateityp keine .src auswählen. Es wird als Dateityp dann "Alle Dateien (*)" verwendet.

Da kann es vorkommen, daß dein Format zerschossen wird und von den Controllern nicht mehr erkannt wird (ging mir bei ABB und KUKA schon so).

Gehe mal so vor : Das Modul, daß du geändert hast, nur noch "speichern", nicht "speichern unter". ( Vorher natürlich Sicherungskopie etc. weißt schon ).

Da bleibt das Format immer erhalten. Hatte nie mehr Probleme.
Vielleicht war ja auch das die Ursache.

Probiers doch mal aus.

Gruß Maddin

Hallo zusammen,

den Versuch das Getriebespiel durch Wackeln zu bestimmen, habe ich schon ganz am Anfang gemacht (mit offenen Bremsen natürlich), aber da ist mir nix außergewöhnliches aufgefallen....
Auch beim inkrementellen Handverfahren könnte man Spiel feststellen, wenn sich die Gradzahl der Achse ändert, aber der Roboter sich anfangs mechanisch nicht bewegt.
Aber auch das war in Ordnung.

Ich habe mit ABB telefoniert, die sind sich ziemlich sicher daß der Motor ne Macke hat, das Getriebe aber in Ordnung ist.
Wird sich zeigen, wenn er getauscht wird.

Die Nutzlast ist im Programm definiert, daß habe ich gleich am Anfang überprüft (GripLoad). Und die Bewegungsüberwachung hochstellen bringt in meinem Fall nichts, da ich eine Achskollision gemeldet bekomme, nicht die Bewegungsüberwachung.

Das Pendel müßt ihr euch folgendermaßen vorstellen. Wenn ich manuell verfahre mit Achse 2, dann pendelt der Roboter wegen des Greifers und dessen Gewicht nach, sobald er zum Stillstand kommt. An der Achse selber ist dies kaum sichtbar, aber am Ende des Armen (Achse 6) kommen da mittlerweile fast 2-3 cm zusammen

Oder stellt euch vor, ihr macht alle Befestigungsschrauben am Robotersockel 2-3 cm auf :ylsuper: Das sieht dann ähnlich aus......

Bis dann

Gruß Martin

Hallo miteinander,

ich habe da ein Problem.

Ein IRB 6650 steigt mir in letzter Zeit häufig aus mit der Meldung "50056 Achskollision Fehler" in Achse 2.
Der Roboter wird zum Abstapeln von Metallplatten verwendet.

Zu dem Zeitpunkt, wenn der Roboter stoppt, ist keine Kollision vorhanden, er kann sich frei bewegen. Er wechselt zu dem Zeitpunkt von einer vertikalen in eine horizontale Bewegung.

Ich beobachte seit geraumer Zeit ein Nachschaukeln oder Pendeln, wenn der Roboter einen Stop-Punkt anfahren muss oder die Richtung wechselt.
Auffällig ist die Achse 2, die auch den Fehler meldet. Auch im Handverfahren ist das Nachschaukeln zu beobachten.

Ich kann mir zur Zeit nur damit behelfen, die Beschleunigung (ACCSET) auf 40% runterzuschrauben. Ich vermute, daß die Getriebe mittlerweile Spiel haben. Aber wie kann ich das feststellen ?
Ich habe mal die Antriebe in Lageregelung gebracht (Bremsen auf) und den Roboter am
Werkzeug gepackt und versucht ihn zu schaukeln.
Dabei ist mir aber nichts besonderes aufgefallen.

Habt Ihr eine Idee ??

Gruß Maddin

Hallo zusammen,

Mit ALT+3. Funtionstaste von links unter Display (F3 ??) kann man Anwendungen schließen.

Müßte auch bei der Online Hilfe funktionieren.
Bin da draufgestoßen, weil man bei Windows die Anwendungen mit ALT+F4 beendet.

Also bin ich die Tasten mal durchgegangen, weil mich die Online Hilfe auch schon mehrmals kalt erwischt hat. :eviltongue:

Gruß maddin

Hallo zusammen,

vielen Dank für eure Antworten.

Das Problem ist nicht das Archivieren, dafür hab ich ja noch das Netzwerk.

Ich mache mir eher Sorgen, wenn wiederhergestellt werden muss. Dies geht nämlich bei uns bis jetzt nur über Diskette. Da habe ich das Problem, daß ich ein über das Netzwerk gezogenes Archiv nicht auf die Diskette bekomme.

Leider kann über das Netzwerk nur "Alles" archiviert werden.

Ich müßte im Archiv dann diverse Sachen löschen, um auf Diskettengröße zu kommen.
Da fehlt mir allerdings die Erfahrung damit.

Deshalb möchte ich versuchen, auch diskettenübergreifend archivieren & wiederherstellen.

Man kann bestimmt auch über Netzwerk wiederherstellen , allerdings fehlt mir hier die Erfahrung, um dies zu konfigurieren.

Ich mache mich mal den KRCKonfigurator.

Bis denne
Maddin

Hallo Kollegen,

ich habe seit heute das Problem, daß die Archivierung über Diskette nicht mehr möglich ist. Es erscheint lediglich die Meldung "Archivierung fehlgeschlagen".
Ich habe zusätzlich die Möglichkeit, über Netzwerk zu archivieren. Dieses Archiv hat ca. 1.26 MB. Ich gehe davon aus, daß das Archiv mittlerweile zu groß ist für Diskette.

Archiviere ich nacheinander : Anwendungen, Maschinendaten & Konfiguration (einzeln) auf eine Diskette, so funktioniert dies. Das Logbuch braucht also sehr viel Speicherplatz.

Leider kann ich über Netzwerk nur archivieren, nicht wiederherstellen. Im Fehlerfall kann ich also nur über Diskette wiederherstellen.

Meine Fragen (viele, viele ) :

- Ist kein diskettenübergreifendes Archivieren möglich??. Wenn ja, wo einstellen ?

- Kann ich das Logbuch "leeren"? Würde mich interessieren, ob Alles Archivieren auf Diskette dann funktioniert.

- Kann das Logbuch von der Anzahl der Aufzeichnungen her eingestellt werden, damit die Log-Dateien nicht zu groß geraten ?

Die Versionen :

KRC v5.2.11
BOF v 1.2.24.0 B67

Hoffe die Versionsinfo ist ausreichend.

Würde mich über Hilfe sehr freuen.

Bis denne
Gruß Maddin

Hallo Paulino,

die Befehle MoveJDO oder MoveLDO könntest du dir mal in der Doku genauer ansehen. Dann wärst du nicht auf das Zonemaß fine angewiesen. Ansonsten normaler SET/RESET Befehl, dann aber nur mit Zonemaß fine, ansonsten wird dein Set/Reset Befehl ausgeführt, bevor der Roboter die Position erreicht (wegen dem Rechnervorlauf).

Gruß maddin

@ SJX & burlibua

Nach den Infos habe ich schon lange gelechzt.....

Vielen Dank auch von mir

Gruß Maddin

Hallo,

also dein Problem kam wohl vom Resolver. Zwar war der Resolver in Ordnung, sonst hättest du eine andere Fehlermeldung erhalten.
Der Resolver muß aber an den Ständer (oder den Läufer ? ...weiß nicht genau) vom Winkel her angepasst sein. Wie dies gemacht wird, keine Ahnung. Wir schicken unsere defekten Motoren immer an den ABB Reparaturservice. Dort wird auf dem Prüfstand der Resolver zum Motor eingestellt. Es kam mal 1 Motor "repariert" zurück, an dem dann dein genanntes Phänomen auftrat: Sobald die Antriebe eingeschaltet wurden und die Motoren in Lageregelung gingen, ist jener Motor durchgegangen und wurde von der Steuerung dann abgeschaltet (Achsgeschwindigkeit zu hoch).
Die Ursache war dann die Verbindung Motorwelle<->Resolver. Die Welle ist vom Resolver rausgewandert und hat den Resolver dann nicht mehr angetrieben....
Was bei dir das Problem war, keine Ahnung. Aber den Resolver auf gut Glück verdrehen, bis es funktioniert, da gewinnste vorher den Lotto- Jackpot...
Der kommutierungs-Offset ist meine ich immer gleich (90°) und nicht auf den Motor angepasst.
Grüßle Maddin

aha !
tststs

solche Fehler .......

Vielleicht kommt er ja nochmal. Dann kann ich ihn aufklären.

Gruß maddin