Zonenbahnfehler Ursachen beheben

    Hier gehts mal nicht die Meldung zu verstecken sondern um die Ursachen zu beheben


    Die Ursachen der Meldung sind ja sehr allgemein beschrieben

    1. Zeitverzögerung ==> Was ist damit gemeint ???
    2. Eng programmierte Punkte. ==> Zonen überschneiden sich nicht
    3. Hohe CPU-Auslastung des Systems. ==> wie kann ich das prüfen genau an dieser Stelle ???

    Welche Mittel gibt es noch um die genaue Ursache zu finden?


    Beheben laut Doku

    • 1. Verringern Sie die Anzahl der Instruktionen zwischen aufeinander folgenden Bewegungsinstruktionen. ==> Was sind zuviel ???
    • 2. Reduzieren Sie die Geschwindigkeit, ==> genau darum will ich das ja beheben !
    • 3. verwenden Sie einen größeren Abstand zwischen den Punkten und die /CONC-Option. ==> Zonen überschneiden sich nicht
    • 4. Erhöhen Sie den Systemparameter „Prefetch Time“ in der Parametergruppe „Motion“, Typ „Motion Planner“. ==> von 0.1 auf 0.3 erhöht
    • 5. Erhöhen Sie den Systemparameter „Interpolation Buffer Startup Adjust“ in der Parametergruppe „Motion“, Typ „Motion Planner“, wenn der Halt bei der ersten Bewegung nach einem Feinpunkt erfolgt. ==> ist nicht die erste Bewegung

    Ich kämpfe schon den ganzen Tag um einen ungewollten Stopp Punkt zu entfernen

    • ANZEIGE

    Hallo erst mal,


    ich kenne das, dass immer mal der Programmzeiger schon auf einer Wartebedingung läuft. WaitDi, WaitUntil o.ä.


    Manchmal kann es ebenfalls sein, dass zweimal der selbe Punkt angefahren wird.


    Wenn dir das möglich ist mal mit einen Trace. Hier kann man normalerweise recht viel sehen.


    Gruß Stingray

    Da ist schon ein WaitUntil danach ….

    zum Prüfen hab ich mal ein TPwrite eingefügt wenn die Bedingung noch nicht True ist


    Punkt doppelt anfahren ist auch klar, hab ich geprüft...


    Trace was meinst du damit genau? Bringt Spylog was?? ist da was zu sehen????



    Die Meldung tritt übrigens erst ab einen Override jenseits von 50 auf.

    unster Steuerung gibt es Signalanalyse Online, damit kann mal Signale aufzeichnen. Hier kann man auch Stoppunkt und Fehlermeldungen aufzeichnen.

    allerdings benötigt man eine Lizens.

    aber man kann sich bei einer Neuinstallation eine für 30 Tage eine Testlizens installieren.


    kannst du das Modul mal Posten?

    Meine Corona Lizens hat sich leider vor ein paar Tagen in Luft aufgelöst


    Was mich noch umtreibt Abhilfe ==>Verringern Sie die Anzahl der Instruktionen zwischen aufeinander folgenden Bewegungsinstruktionen

    Ich springe schon aus einer Routine in eine andere und auch ein paar IF's werden da mit verlassen


    was ist mit wenn ich das Werkobjekt ändere, mir ist so als ob das auch mal ein Problem in diese Richtung auslösen kann. Bin mir da aber nicht so sicher.

    Die If bedingenen könnten was sein. aber ohne das Programm zu kennen sehr schwer zu beurteilen.


    das wechseln der Werkobjekte sollte eigentlich nicht dazu führen.

    Bleibt der Roboter auch stehen? oder kommt nur die Meldung?


    Prinzipell kommt die meldung dann, Wenn der roboter seine zohne erreicht hat, aber der Programmzeiger noch auf keinem Neuen Fahrbefehl steht, so das er nicht überschleifen kann.


    ich bin mir nicht ganz sicher, aber wird in der meldung nicht angegeben an welchem Punkt der fehler auftritt?


    man kann die Meldung auch ausschalten!

    Ja der Roboter bleibt stehen und frisst meine Tatzeit

    Ja die Zeile steht drin wo es auftritt

    Morgen Probier ich mal als erstes die Conc Option, obwohl ich die noch nie erfolgreich benutzt habe


    Ich muss 2 jobs Zusammenfassen, aber der Aufbau ist halt dadurch so auf einzelne Routinen verteilt das da schon einiges an Code dazwischen ist. Wenn ich wüsste das daran liegt ist das ja behebbar aber so kann es halt so vieles anderes auch sein

    Hallo RobiMan

    zu einem Stopp-Punkt kommt es auch, wenn in einer If-Bedingung ein Signal erst nach der erfolgten Bahnplanung gültig wird. So etwas ist nicht offensichtlich es sieht alles gut aus, aber mit dem RobotStudio Analyzer, Bahngeschwindigkeit und Zohnenbetrachtung aufgezoomt kommt man dahinter.
    Wenn Du die Option /CONC einsetzt sollte Dir klar sein das bei einem auf der Bahn manuell ausgelösten Stopp schon die darauffolgenden Instruktionen ausgeführt wurden. Das ist schwer beherrschbar, ich nutze das nicht.

    Gibt es noch Signallaufzeiten? Langsame E/A-Karte, Polling anstatt COS, das hat mir mal nen ganzen Tag versaut.

    Aber so wie sich das jetzt ließt sind das mehr Aufgaben als es der Rechner es zur geplanten Strecke der Bahn schafft.

    DSQC639? Multitasking? Manchmal braucht ein System auch mal eine Erholzeit mit WaitTime /inPos!

    WaitUntil ist langsam (manchmal nach längerem Halt aber nötig) und ein TPWrite macht das auch nicht besser, mir wurde davon beim IRC5 unbedingt abgeraten.

    Gruß, Konstantin

    Es schein echt knapp zu sein, ab und zu hält der Roboter trotzdem doch noch kurz an.


    nochmal zur Sicherheit: \Conc bedeutet ja das der Roboter nicht wartet bis die Ziel Zone erreicht ist, sondern das der BZ sofort weiterläuft...hab ich das so richtig verstanden?


    Konstantin, das sind schon noch ein paar gute Denkansätze

    Ja ich hab Multitasking mit noch 2 anderen ständig laufenden Tasks

    RW ist 6.11 auf einen neuen Compact Controller

    zu den IF und Bahnplanung: wenn der Bahnplaner/Vorlaufzeiger drüber läuft wird das IF ausgewertet und nicht erst wenn der PZ ankommt.

    Damit sollte ja mein TPwrite anzeigen was zu diesen Zeitpunkt zutrifft oder ist meine Denke da falsch?

    Hallo RobiMan

    TPWrite zeigt Dir das dann genau an. Ist aber langsam bis hoch zum Display.
    Damals bei ca. RW5.05 wurde mir von TPWrite abgeraten, da dies Schreibzyklen auf der Festplatte verursachen sollte.

    Es gibt ja die MessageBox.

    Noch etwas: Wenn der Roboter online per RobotStudio beobachtet wird kostet das auch etwas Taktzeit.

    Gruß, Konstantin

    Hm ich denke das Prolblem liegt daran, dass der Fahrbefehl einer Schleife liegt.


    Der Programm zeiger ist voreilent, abhänig von der Auslastung.

    Die Schleife läuft 1000 mal durch, je nachdem wie weit deine Punkte auseinander ist der Bahninterpereter schon 5 oder 10 Punkte voraus, da die Schleife quasi ungebremst läuft.


    Dein TP-Write bremst aber die Schleife enorm aus. so dass der Programmzeiger nicht mehr mit kommt. Aus diesem Grund sind Write befehle in welcher art auch immer schlecht in schleifen.


    hab schon 10 Sec zykluszeit rausgeholt nur durch löschen von write befehle.

    Hey,


    Hatte genau denselben Fehler. Ich hatte bei mir die Verwendung von AccSet im Verdacht. Als ich stattdessen PathAccLim verwendet hatte, war es wieder gut. Zumindest schien es so.


    Nun habe ich erneut dieses Phänomen. Hab auch einige Zohnenbahn-Fehler Warnungen immer wieder im Programm. Diese lassen sich aber kaum "beheben", da oft zu Beginn einer Fahrt-Routine eine Vorposition angefahren wird, die vielleicht schon angefahren wurde, bzw. der Roboter gerade am Weg dahin ist.


    Vielleicht ist \CONC eine Option für mich.

    TPWrites werde ich auch mal eleminieren.

    Hätte ein oder mehrere WaitDI vor jedem Zyklus (Job-handshake).


    Falls ich weiter Hilfe brauche, vielleicht könnt ihr mich da noch unterstützen? Vor allem mit diesem Trace... Kenn mich zwar bissl aus mit dem SignalAnalyzer, aber wie das mit Fehlermeldungen und Stoppunkten genau funktioniert könnt ich vermutlich Hilfe gebrauchen.


    BG Reinhard

Hilfe und Support für ABB Roboter Programmierung, Konfiguration, Inbetriebnahme finden Sie hier im ABB Roboter Forum. ABB Rapid Programmierung ist einfach, die Roboterforum Community hilft sehr gerne.

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden