Beiträge von Drudge

    Danke Fast und Otto Sieben für euer Bemühen. ;)



    Ich konnte heute morgen die Hotline DE erreichen. Der Fehler ist der Hotline inzwischen bekannt:
    Es wird bei der Installation ein Ordner nicht erstellt. Im Verzeichnis [C:\Users\Benutzername\Documents\WorkVisual Projects] müssen sich folgende Ordner befinden:
    [list type=decimal]

    • Downloaded Options

    • Downloaded Projects

    [/list]
    Sobald diese Ordner existieren, funktioniert das Runterladen der Projekte mit dem WoV 4.0.21 B126 wieder.


    Gruss Drudge


    P.S.
    Downgrade war für mich keine Option, da das Projekt auf dem Roboter mit WoV 4.0.21 B126 erstellt worden ist.

    Ja aus einem Archiv oder KRCDiag kann ich das Projekt fehlerfrei öffnen.
    Das mit dem Wackel ... bist du sicher? Denn das Runterladen des Projektes vom Roboter scheint zu funktionieren, nur das anschliessende Laden/Öffnen bricht mit dem genannten Fehler ab. Auch die Onlineverbindung für Diagnose etc. funktioniert über das Ethernet ...

    Hallo zusammen,


    ich habe nun nach einiger Zeit wiedermal die Ehre eine KRC4 in Betrieb zu nehmen. Hab sie ausgepackt, Datensicherung gemacht und wollte nun das Projekt von der nagelneuen Steuerung auf den Laptop laden für die Buskonfiguration. Es klapt alles soweit, jedoch nach >90% laden, bricht das WorkVisual ab und es kommt folgende Fehlermeldung:

    Zitat

    Beim Abrufen von Projektinformationen für Projekt "xyz" von "Robi1 - (172.31.1.147)" ist ein unbekannter Fehler aufgetreten: Ein Teil des Pfads konnte nicht gefunden werden.


    Installiert ist das KSS V8.3.29 Build 219 und dabei war das WorkVisual V4.0.21_Build0126.


    danke!

    - es gibt die Möglichkeit, dass die Programmebene in der der Pulse gestartet wurde, durch einen Interrupt abgebrochen wird (RESUME)
    - oder jemand (Bediener, Submit, Trigger, Interrupt, ...) schaltet den Ausgaung kurz nach dessen Ausschalten durch PULSE wieder ein
    für eine aussagekräftigere Antwort müssten wir das Programmarchiv, bei dem der Fehler auftritt, haben.

    - sitzt die MFC sauber im PCI Slot?
    - sitzen die Stecker auf der MFC und RDW alle sauber und fest?
    - sind alle Krimpkontakte in Ordnung?
    - wie ist der Blinkcode auf der DSE im Fehlerfall? (verm. dunkel?)
    - sind die Kabel zwischen STeuerung und Roboter in Ordnung?
    - schon mal versucht die MFC/DSE oder RDW zu ersetzen?
    - habt ihr wärend der Produktion eventuell sporadische Fehlerstopps des Roboters?

    soweit ich weiss, gibt es keine Möglichkeit dazu ... wieso machst du nicht einfach die Namen "Bahn1_1", "Bahn1_2" etc.? Du kannst ja immernoch dazwischen einfügen "Bahn1_1_5" usw.
    Am besten erstellst du ein Programm mit den 200 Punkten und speicherst es als Vorlage ab, so dass du nicht jedes mal die Punkte erstellen musst. (rauslöschen ist ja dann easy)
    Oder du verwendest den Notepad++ Editor, modifizierst die zweihundert Positionen mit z.B. dem Namen "Bahn1_1" mithilfe des Suchen-Ersetzen Funktion mit Regulären Ausdrücken und der Makrofunktion. So dass am Schluss bei jeder Position noch eine Null angefügt ist.

    es gibt zwar kooperierende Roboter, doch sehe ich darin keine Lösung für dein Problem.


    Auch empfinde ich eine Regelung, dass die Roboter gegenseitig einen Mindestabstand einhalten sollen, nicht sehr schlau. (Deadlock)


    pragmatischer wäre einige Bereiche zu definieren für jeden Roboter. Diese könnten dann über digitale Signale jeweils dem anderen Roboter kommuniziert werden. (1 = Robi befindet sich in diesem Bereich; 0 = Bereich ist wahrscheinlich frei)


    Der Submit könnte das überwachen und entsprechende Aktionen oder Interrupts auslösen. (beachte Signallaufzeit -> Verriegelung und Freigabe jeweils doppelt prüfen ...)


    Mit einer Zustandsgesteuerten Programmierung (SWITCH) kann dann jeweils je nach Situation der entsprechende Arbeitsschritt ausgeführt werden. (achtung den Vorlaufzeiger möglichs nicht wärend einer Bewegung aufhalten ...)


    greetz

    Hallo zusammen,


    ich habe an einem ABB Roboter folgende Fehlermeldung jedes Mal, wenn ich eine Bestimmte Naht schweisse. Meistens passiert nichts, doch manchmal bleit der Roboter stehen. Nun nimmt es mich wunder was die Meldung genau bedeutet, respektive was ihre Ursache ist. Irgendwie konnte ich mit der Suchfunktion und in den Manuals unter "POST2END" oder "Signalfehler" nichts finden.


    Fehlermeldung:

    Zitat

    Allgemeine Logmeldungen
    SeqNr Typ Kategorie Fehlernummer Bezeichnung Datum Beschreibung Argumente
    1421789 E Prozess 110471 Nicht definierter Signalfehler 2014-12-11 09:10:01 T_ROB1Fehlerhaftes Signal während Schweißphase POST2END konnte nicht bestimmt werden. {args: "T_ROB1", "/Zarge_li_Typ1/rZarge_li_Typ1/ArcLEnd/148", "POST2END"}


    Betroffener Codeabschnitt

    Code
    MoveL pVorP_SpFa , vNormalL, z5, tWH_455, \WObj:=WOBJ_ACT;
        ArcLStart pStart_SpFa , vAccurL, sUeberkopf, wUeberkopf \Weave:=wPendelnBreit, 
                      fine, tWH_455 \WObj:=WOBJ_ACT;
        ArcL pHP_SpFa, vAccurL, sUeberkopf, wUeberkopf \Weave:=wPendelnBreit, 
                      z5, tWH_455, \WObj:=WOBJ_ACT;
        ArcLEnd pEnd_SpFa , vAccurL, sUeberkopf, wUeberkopf \Weave:=wPendelnBreit, 
                      fine, tWH_455 \WObj:=WOBJ_ACT;
        MoveL pNachP_SpFa , vNormalL, z5, tWH_455, \WObj:=WOBJ_ACT;


    verwendete globale Variablen

    Code
    LOCAL PERS robtarget pEnd_SpFa := [ [9.07107, -0.94, -2.27], [0.0482569, 0.0888035, 0.994852, 0.00745093], [0, 1, 1, 0], [ 9E+09, 9E+09, 9E+09, 9E+09, 9E+09, 9E+09] ];
    PERS speeddata vAccurL := [150, 50, 5000, 1000];
    PERS seamdata sUeberkopf:= [0,0.8,[0,0,0,100,0,0,0,0,0],0,0,5,0,20,[0,0,-5.2,104,0,0,0,0,0],0,0,[0,0,0,0,0,0,0,0,0],0.8,0,[0,0,0,0,0,0,0,0,0],0.3];
    PERS welddata wUeberkopf :=[5,0,[0,0,-10,100,0,0,0,0,0],[0,0,0,0,0,0,0,0,0]];
    PERS weavedata wPendelnBreit := [1,0,2,3,0,0,0,0,0,0,0,0,0,0,0];


    Hat irgend jemand eine Idee? Wäre froh drum :D

    Vermutlich smartpad getausch und alte KSS Version auf der Steuerung? (ca. KSS 8.2.7 oder so) Falls das der FAll ist, musst du das SmartPAD downgraden. Oder aber dein System komplett upgraden.

    Lieber Harzi,


    Es ist richtig dass beides ProfiNet und WindowsNetzwerk nur über das KLI funktionieren. Wenn du die beiden Netze getrennt haben möchtest, solltest du folgendes tun:


    1. Du musst in der Netzwerkkonfiguratione (KLI-Config) zwei virtuelle Netze definieren. (Dabei musst du darauf achten, dass das Subnet für ProfiNet die höhere Prio hat, als das normale Windowsnetzwerk.)
    2. Dann kaufst du dir einen Managed Switch und konfigurierst ein port mit erhöter Prio für ProfiNet



    greetz Drudge

    Ist noch schwierig zu beantworten ... Es kommt nämlich draufan! KRC1 und KRC2 (bis KSS V5 und V7) war mir das Benützen der Mouse zu blöde und umständlich. Doch seit KRC4 mit KSS8 finde ich die Maus super :) - solange ich kartesisch fahren muss. Für achsspeziefisches Verfahren sind immernoch die Tasten Trumpf :P

    Hallo zusammen,


    ich möchte das Problem nochmals aufgreifen. Hatten das gleiche Problem an mehreren Robotern (Maximales Getriebemoment A5 oder A6). Zuerst war es an zwei KR60-3 mit KSS8.2.17. Nach der Lastdatenermittlung durch einen KUKA Techniker schien der Fehler weg. Es ist aber so, dass der Fehler lediglich sehr viel weniger oft auftritt. Die Lastdaten konnten nur für einen bestimmten Greiferzustand ohne Material im Greifer gependelt werden. Dann war da noch ein KR16-2 mit KSS V8.2.20. Auch da wurde das Problem durch das Eingeben von richtigen Lastdaten (bis jetzt) behoben. Des Weiteren haben wir einen KR 30 mit KSS V8.2.19, dem zwar Lastdaten eingetragen wurden, diese aber aus verschiedenen Gründen nicht immer 100% korrekt sein können. Auch dieser bleibt immer wieder mal stehen (beim Anfahren) mit "maximales Getriebemoment A5".


    Kann es eventuell sein, dass das Fehlertoleranzfenster so klein gemacht wurde, dass die Realität daran scheitert? Gibt es noch weitere "Tricks" ausser den Versuch Lastdaten nach bestem Wissen und Gewissen einzutragen?


    lg Drudge