MoveJSync MoveLSync Problem bei Funktionsaufruf

  • Hallo liebe Roboter-Community,


    leider konnte ich zu meinem Problem keine passende Lösung finden, also versuche ich es hier.


    Mein ABB IRB2600 (Robotware 6.13.04.00) macht Probleme beim Abarbeiten des MoveJSync/MoveLSync.


    Einer der Befehle, der Probleme macht:


    MoveJSync pHome,vVorpos,fine,toGreifer\WObj:=wobj0,"MerkerHome";


    PROC MerkerHome()

    !

    bVorposLL:=FALSE;

    bVorposLR:=FALSE;

    !

    ENDPROC


    Die Bits, die die Prozedur (in diesem Fall) auf FALSE setzt, werden im Programmablauf für die Steuerung der Abfolge der Funktionsaufrufe verwendet. Das Problem ist jedoch, dass die Bits im Automatikbetrieb definitiv nicht FALSE gesetzt werden (habe ich mehrmals verfolgt und kontrolliert). Die Bits werden ziemlich bald nach dem Aufruf der MerkerHome-Prozedur in einer IF abgefragt.


    Ich habe daraufhin folgendes ins Programm hinzugefügt:


    MoveJSync pHome,vVorpos,fine,toGreifer\WObj:=wobj0,"MerkerHome";

    bVorposLL:=FALSE;

    bVorposLR:=FALSE;


    So setzt der Roboter nach der Prozedur "MerkerHome" die Bits definitiv wie gewünscht und alles läuft so wie es soll. Das Problem hatte ich bei allen MoveJSync/MoveLSync-Befehlen im Programm. Ich habe überall die Bitzuweisung darunter eingefügt und es passt.


    Frage nun:


    Warum funktioniert das Zuweisen mit MoveJSync (selbes Spiel mit MoveLSync) nicht? An der Funktion des Programms habe ich ja nichts geändert, nur weil ich die Zuweisung unter den MoveJSync/MoveLSync-Befehl geschrieben habe.


    Danke für eure Hilfe! :)


    LG Sebastian

  • ANZEIGE
  • Das Problem ist jedoch, dass die Bits im Automatikbetrieb definitiv nicht FALSE gesetzt werden (habe ich mehrmals verfolgt und kontrolliert).

    Gar nie nicht oder nur nicht zum richtigen Zeitpunkt?

    Die Bits werden ziemlich bald nach dem Aufruf der MerkerHome-Prozedur in einer IF abgefragt.

    Asynchron? Wie bald ist bald?


    Könnte mir vorstellen, dass Du in eines der typischen Satzvorlauf-Probleme gefallen bist. Wenn Du Bits bewegungssynchron setzt, aber "bald danach" asynchron abfragst, erfolgt die Abfrage u. U. lange bevor die Bewegung überhaupt an der Synchron-Position ankommt.

    Wenn Du sie ebenfalls asynchron setzt, stimmt die Reihenfolge natürlich wieder.

  • Also das wird so nicht funktionieren.

    1. du verwendest FINE -> Damit ist ein MoveSync überflüssig da der PZ eh erst nach erreichen und einregeln der Position weiter macht.

    2. MoveSync verwendet den Verschleifbogen, da hier der Aufruf der Routine gestartet wird und je nach Prozessorauslastung du hier nach diesem Punkt eine Abarbeitung der Routine erwarten kannst. Achtung diese Abarbeitung hat nichts mit dem Pfad vom Roboter zu tun sondern ist Prozessorauslastungsabhängig. s.h. Referenzhandbuch -> MoveL/JSync


    Deine Routine kann direkt hinter deiner Bewegung stehen und würde damit Funktionieren.


    Kurze Frage: Warum hast du dich hier für ein MoveSync entschieden?


    Gruß

    Wer nichts macht, macht keine Fehler!

    Wer keine Fehler macht, kann nichts daraus lernen!

    Wer nichts lernen kann, kann sich nicht weiterentwickeln!

    Wer sich nicht entwickelt, geht unter!

  • Danke für deine Antwort!


    Gar nie nicht oder nur nicht zum richtigen Zeitpunkt?

    Kommt drauf an. Wenn ich das Programm kurz darauf stoppe, sind die Bits nicht richtig gesetzt. Wenn der Roboter aber nach der IF-Abfrage mit den falsch gesetzten Bits in den falschen Block spring und einen Crash fährt, dann sind die Bits im nachhinein richtig gewesen, was mir natürlich Kopfschmerzen bereitet hat, weil der IF-Block, in dem er da gestanden ist, ja dann eigentlich nicht mehr erfüllt war und den Bits währenddessen nichts anderes zugewiesen worden ist (Also der hätte da nicht sein sollen). Also es hat schon gedauert, bis ich die MoveJSync/MoveLSync als Problem identifizieren konnte.

    Asynchron?

    Ich arbeite genau einen Task ab. Ich bin noch kein Spezialist auf dem Gebiet, aber ich denke, da der Roboter das Programm ja Satz für Satz abarbeitet, sollte es ja Grundsätzlich funktionieren.


    Wie bald ist bald?

    Bald heißt, dass das Bit gesetzt wird und ein paar Sätze darauf (ist schwer zu sagen wie viele weil das Abhängig vom Programmablauf ist) in einer IF abgefragt wird.


    Könnte mir vorstellen, dass Du in eines der typischen Satzvorlauf-Probleme gefallen bist. Wenn Du Bits bewegungssynchron setzt, aber "bald danach" asynchron abfragst, erfolgt die Abfrage u. U. lange bevor die Bewegung überhaupt an der Synchron-Position ankommt.

    Wenn Du sie ebenfalls asynchron setzt, stimmt die Reihenfolge natürlich wieder.

    Heißt das, dass ich in meinem Fall den MoveJSync/MoveLSync-Befehl nicht verwenden darf? Oder wie genau darf ich das verstehen? Ich dachte, dass der Synchron zur Bewegung die Bits setzt. Und wenn ich die Nach der Bewegung abfrage, sind die gesetzt wie gewollt?


    LG Sebastian

  • 1. du verwendest FINE -> Damit ist ein MoveSync überflüssig da der PZ eh erst nach erreichen und einregeln der Position weiter macht.

    Bei z<> fine passiert leider das selbe. Ich habe einfach einen der vielen MoveJSync/MoveLSync kopiert, der hatte zufällig fine.


    2. MoveSync verwendet den Verschleifbogen, da hier der Aufruf der Routine gestartet wird und je nach Prozessorauslastung du hier nach diesem Punkt eine Abarbeitung der Routine erwarten kannst. Achtung diese Abarbeitung hat nichts mit dem Pfad vom Roboter zu tun sondern ist Prozessorauslastungsabhängig. s.h. Referenzhandbuch -> MoveL/JSync

    Wenn ich die Prozedur nach der Bewegung Aufrufe funktionierts. Soweit klar weil er ja Satz für Satz abarbeitet. Nur was ist der Unterschied zu MoveJSync/MoveLSync? Aus dem Referenzhandbuch werde ich zwar schlauer, aber so ganz hatte ich noch nicht die erleuchtung.


    LG

  • Ich dachte, dass der Synchron zur Bewegung die Bits setzt. Und wenn ich die Nach der Bewegung abfrage, sind die gesetzt wie gewollt?

    Die erste Annahme ist ungefähr richtig (siehe Einschränkungen im Handbuch und Svens Ergänzungen). Die zweite ist das Problem. Das "danach" ist nicht wirklich danach.

    Der IF-Abfrageblock ist schon längst vom Programmzeiger durchlaufen worden, bevor der Bewegungszeiger in die Nähe Deiner MoveJSync kommt. Das Problem stellt sich häufig auch bei Eingangs-Signalabfragen und ist Quelle endlosen Ungemachs.

    Im Grunde ist es nicht möglich, eine logische Entscheidung auf diese Weise zu treffen, ohne den Satzvorlauf zu synchronisieren. WaitTime \InPos,0; z. B., oder man wartet vor der IF-Entscheidung so lange, bis die SYNC-Routine durch einen dritten Merker zu verstehen gegeben hat, dass sie durch ist.


    Wenn es darauf ankommt, dass die _Position_ erreicht wurde, ist Move*Sync sinnvoll und nötig. Wenn Du nur sichergehen willst, dass der _Programmteil durchlaufen_ wurde, brauchst Du kein Sync.

  • Die erste Annahme ist ungefähr richtig (siehe Einschränkungen im Handbuch und Svens Ergänzungen). Die zweite ist das Problem. Das "danach" ist nicht wirklich danach.

    Der IF-Abfrageblock ist schon längst vom Programmzeiger durchlaufen worden, bevor der Bewegungszeiger in die Nähe Deiner MoveJSync kommt. Das Problem stellt sich häufig auch bei Eingangs-Signalabfragen und ist Quelle endlosen Ungemachs.

    Im Grunde ist es nicht möglich, eine logische Entscheidung auf diese Weise zu treffen, ohne den Satzvorlauf zu synchronisieren. WaitTime \InPos,0; z. B., oder man wartet vor der IF-Entscheidung so lange, bis die SYNC-Routine durch einen dritten Merker zu verstehen gegeben hat, dass sie durch ist.


    Wenn es darauf ankommt, dass die _Position_ erreicht wurde, ist Move*Sync sinnvoll und nötig. Wenn Du nur sichergehen willst, dass der _Programmteil durchlaufen_ wurde, brauchst Du kein Sync

    Danke vielmals für die Antwort. Auf meiner To-Do-Liste steht bereits, die ganzen Move*Sync aus dem Programm zu verbannen. Ich denke ich habe die Funktionsweise jetzt verstanden. Ihr habt mir sehr geholfen!


    LG Sebastian :)

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