Achseweise Bewegung mittels Variablen

  • Hallo zusammen,
    Ich hab bei uns gestern eine Mast-Slave Anwendung mit einem KR6 in Betrieb genommen. Der Robi bekommt von einem Master Modell Werte für die Achsen zugeschickt und folgt dann anschließend den Bewegungen des Master Modells. Soweit funktioniert alles. Ich kann die Achswerte an die Steuerung senden und auch in Bewegungne umsetzen. Umgesetzt habe ich das ganze Programm so ähnlich wie in dem Post https://www.roboterforum.de/ro…iben/1261/msg2254#msg2254 . Bei testen ist mir nur aufgefallen, dass der Roboter nicht alle Achsen gleichzeitig bewegt, sondern immer nur eine Achse nach der anderen. Bedeutet ich bewege im Modell die 1 und die 2 Achse gleichzeitig und der Robi bewegt zuerst nur die erste und dann die zweite Achse. Wie schaffe ich es, dass alle Achsen zugleich bewegt werden. Dazu gleich einmal der Code den ich verwende:



    SlavePos ist bei mir als AXIS im .dat hinterlegt. Bei der Programmierung bin ich davon ausgegangen, dass zuerst die einzelnen werte eingelesen werden und dann alle Achsen, den zugewiesenen Wert annehmen, jetzt zeigt sich in den Tests aber, dass eine Achse nach der anderen ausgerichtet werden. Hat jemand einen Tipp, mit welchem Verfahrbefel ich eine gleichzeitige Bewegung erreichen kann. Zusätzlich würde ich gerne die Geschwindigkeit bei den achseweisen Bewegungen unabhängig von den SPTP Home Befehlen steuern. Gefunden hab ich dazu nur den Befehl $VEL_AXIS[1]=SVEL_JOINT(15). Muss ich hier für jede Achse einzeln die Geschwindigkeit festlegen, oder kann ich das gleich für alle Achsen mit einem Befehl machen?
    Grüße
    newbie

  • Schritt für Schritt zum Roboterprofi!
  • Hallo Newbie,
    Liest Du die Daten ein via sps.sub? Poste mal dieses Prog.
    Wie es aussieht fehlt die Koordination zwischen den beiden Interpretern.


    Gruss SJX

    Manche Maenner bemuehen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitaetstheorie.

  • Hi,
    die Daten werden von mir mittels eines Python-Scripts und KukaVarProxy direkt auf die Steuerung geschrieben. Ich hab die Variablen MA1 - MA5 in der $config.dat angelegt und kann sie mittels VarProxy beschreiben. DAS MasterSlave.src greift auf die globalen Variablen zu. Daher passiert nichts im SPS.sub. Du meinst ich muss eine Synchronisierung zwischen dem schreibenden Python-Scritp und dem lesenden Roboter aufbauen?

  • Hallo,
    du musst natürlich sowas einbauen wie einen Handshake zwischen deinem Hauptprogramm und der Schnittstelle.Du hattest jetzt immer ein zeitliches Problem. Du hast deine SlavePos beschrieben da stand noch gar nicht in allen MA`s was drin.
    Rein theoretisch muss du mit deinem Varproxy noch eine Variable machen die meldet neue Daten bereit. Das heisst du hast alle uebergeben.
    Wenn das Signal kommt machst du dein beschreiben der SlavePos und wenn das durchgelaufen ist setzt du eine weiter lokale Variable, die dann wiederum abgefragt wird um den Fahrbefehl zu starten. Diese lokale Variable setzt du nach dem Bewegungsbefehl gleich wieder auf False.
    Noch besser ist es dieses beschreiben der SlavePos im Sub zu machen und im SRC eine If wenn das erfolgt ist, dann Fahrbefehl.
    Kannst alles schön mit kleinen UPs machen.
    VG

  • Ich hab jetzt probiert einen Handshake mit zwei zusätzlichen Variablen einzubauen, aber der Roboter bewegt immer noch eine Achse nach der anderen. Eingeführt habe ich die Variablen MWriting (Master schreibt) und SMoving (Slave bewegt sich). Im KUKA Programm überprüfe ich ob der Master Schreibt. Wenn nicht geschrieben wird. Setze ich SMoving auf TRUE und sperre damit jede weiteren Schreibbefehl. Dann lese ich die Achsen aus und bewege mich. Sobald der Robi fertig ist wird SMoving auf FALSE gesetzt. Der KRL Code dafür sieht vollgendermaßen aus.



    In Python hab ich natürlich auch den Handshake eingebaut :

    Code
    flag = robot.read("SMoving")
    
    if flag == 'FALSE':
        robot.write("MWriting", True)
        robot.write("MA1",A_1)
        robot.write("MA2",A_2)
        robot.write("MA3",A_3)
        robot.write("MA4",A_4)
        robot.write("MA5",A_5)
        robot.write("MWriting", False)


    Die Daten werden nach wie vor übertragen, die Achsbewegungen finden nur nacheinander statt.

  • Ich hab den Fehler gerade gefunden. Anscheinend benötigt man eine Wartezeit sowohl im Python Script als auch im KUKA Programm bevor man den Handshake abschließt.Wenn man vor "[size=1][font="dejavu sans mono", monaco, "lucida console", "courier new", monospace]SMOVING = FALSE[/font][/size]" und "[size=1][font="dejavu sans mono", monaco, "lucida console", "courier new", monospace]robot.write("MWriting", FALSE)[/font][/size]" jeweils eine Pause einbaut, funktioniert das Programm wie gewünscht und er bewegt mehrere Achsen zusammen.

  • Aber auch nur zufällig, weil Du die Wahrscheinlichkeit drastisch erhöhst, dass der eine dem anderen nicht in die Schleife grätscht. Ein Handshake ist das nämlich nicht.
    "Roll" deine Ketten innerhalb der Schleife mal, dann wirst Du feststellen, dass SMOVING=FALSE und SMOVING=TRUE zeitlich unmittelbar aufeinanderfolgen. Klar, da kann man jetzt eine Pause reindengeln und hoffen, dass der andere Partner immer in die Pause schießt - wird er aber nicht.

    Für einen Handshake bräuchtest Du mehr. p: "Solang du fährst, mache ich nix, aber wenn du fertig bist mit fahren, dann warte mal - ich hab da was" - r: "okay, verstanden, ich höre jetzt, gibs mir" - p: "so, jetzt hast du alles, kannst loslegen" - r: "okay, ich leg jetzt los" - p: von vorne....


    Mag für Dich gerade pragmatisch egal sein, aber besser ist es, sich gleich über solche Probleme bewusst zu werden. Diese Fehlannahmen zu Interaktionen zwischen mehreren Tasks sind nämlich, generalisiert, die berühmten Fälle, in denen man wochenlang auf der Baustelle verbringt, weil undefiniert zweimal täglich irgendwas knallt, was zwischendurch 42000 mal klappt. Sei gewarnt.


    Grüße,
    Michael

  • Zitat

    [size=1][font=verdana, sans-serif]Aber auch nur zufällig, weil Du die Wahrscheinlichkeit drastisch erhöhst, dass der eine dem anderen nicht in die Schleife grätscht. Ein Handshake ist das nämlich nicht. [/font][/size]


    Programmiersklave: Vielen Dank für das Feedback. Ich hab mir deinen Rat jetzt nochmal angeschaut und daraufhin die beiden Programme nochmals von neuem überarbeitet. Mit dem Python Code werde ich hier aber nicht quälen, da es dafür andere Orte gibt. Nur zum KRL Code hätte ich noch ein paar Fragen. Ich habe den Code in der Loop einmal in zwei Bereiche geteilt. Einmal ist keine neue Information vom Master erhältlich, heißt folglich, ich muss keine neuen Werte lesen und kann mich bewegen. Ist Available gesetzt so warte ich bis MWriting einmal True gesetzt wird. Danach wird gewartet, dass MWriting wieder False wird. Jetzt müsste sichergestellt sein, dass der Master die Daten vollständig geschrieben hat. Danach ließt der Robi gleich einmal die neuen Werte ein und setzt ein Signal, dass er die neu eingelesene werte noch nicht abgearbeitet hat. Jetzt Verfährt der Roboter und meldet anschließend wieder, dass alles abgearbeitet wurde.





    Ich hoffe ich habe deine Anregungen richtig interpretiert und auch in einer Form umgesetzt, bei der man nicht ewig den Fehler suchen muss, weil "irgendwas knall".
    Grüße
    Bernhard

  • Hallo Bernhard,


    sieht nun eindeutiger aus, was "Master" und "Slave" angeht, kann mich jetzt nicht in Details hängen.


    Das Problem zieht sich generell subtil durch alle Bereiche, wo mehrere unabhängige serielle Programmabläufe miteinander agieren und Daten und Signale austauschen. Im extremsten Fall kommt es dann sogar vor, dass beide Parteien gleichzeitig den Sperrmerker des anderen abfragen, keine Sperre sehen, und dann gleichzeitig in der folgenden Anweisung den eigenen Sperrmerker setzen. Wenn dann noch eine IO-Karte mit 20 ms Pollrate involviert ist....


    Grüße,
    Michael

  • Hallo newbiemechatronic,
    der zweite Teil deiner Frage (die Veränderung der Verfahrgeschwindigkeit) ging glaube ich etwas unter. Falls du es mittlerweile nicht selbst rausbekommen hast:
    BAS (#VEL_PTP, X) wobei "X" für die prozentuale Verfahrgeschwindigkeit steht.
    Grüße
    DerWerner

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