Beiträge von Maverick

    Hi Hermann,


    ich merke schon ich habe mich etwas falsch ausgedrückt, aber danke für deinen Denkansatz. Vielleicht bekomme ich damit trotzdem was hin.


    Generell geht es immer nur um ein Blech. Wenn der Robi es nicht schafft das Blech zu holen sollte er den Winkel um 5° ändern, zurück fahren und nochmal versuchen das Blech zu holen bzw. Vakuum aufzubauen. Danach nochmal, falls es wieder nicht funktioniert.
    Nach 2 Versuchen gibt's nen Abbruch (der ist aber kein Problem :zwink:).


    Mit "pos_aktuell = $POS_ACT" werte ich sowieso nur den "X-Wert" der Position aus, somit wird der Winkel beim nächsten Anfahren nicht übernommen. Soll er ja auch nicht. Denn das nächste Blech, wenn er das eine dann geschafft hat soll wieder normal angefahren werden.


    Das Problem im Moment besteht im Weitermachen nach dem "DEF Anhalten ()" wenn nicht RESUME benutzt wird. Dann will er nämlich die Fahrt, die durch den Interrupt "Anhalten" im "Suchlauf ()" unterbrochen wurde einfach wieder fortsetzen. Das funktioniert, wenn er stehen bleibt, aber nicht, wenn sich seine Position auf einmal verändert. Muss ich die SLIN_endpos dann nochmal neu aufrufen? Denke das liegt daran, dass er sich die Interrupt-Position merkt und nach dem Interrupt da wieder weiter machen möchte, aber ja nicht kann, wenn er da nicht mehr steht:denk:?

    Hi liebe Forumuser,


    ich habe nochmal eine Frage an euch und vielleicht könnt ihr mir Programmtechnisch dabei ja helfen.


    Folgendes ist vorzufinden:


    Der KUKA muss Senkrecht nebeneinander stehende Bleche (ca. 10mm Abstand) aus einem Magazin mit einem Vakuumsauger entnehmen (siehe Foto anbei -> Draufsicht).

    Dazu fährt der Robi in das Magazin auf einen Startpunkt (ganz Rechts), stellt das Vakuum ein und startet einen Suchlauf bis zum Endpunkt (ganz links im Magazin).

    Sobald ein Blech erreicht wird, meldet das Vakuumventil "Vakuum aufgebaut" und startet den Interrupt um mit dem Blech aus dem Magazin zu fahren.

    Diese Pposition wird immer gespeichert, damit der Robi beim nächsten Anfahren 10mm vor dem letzten "Abholpunkt" startet.

    Sollte kein Blech vorhanden sein, fährt der Robi bis zum Ende des Magazins, gibt der SPS durch, dass das Magazin leer ist, schaltet Vakuum ab und fährt aus dem Magazin.


    Ein zusätzlicher Interrupt mit einem Bauteilsensor am Sauger soll verhindern, dass die Bleche verbogen werden, falls sich das Vakuum nicht aufbaut.

    Das ist so gelöst, dass dieser nach einer gewissen Zeit (wenn Blech 3 sek. erkannt und kein Vakuum aufgebaut) auslöst. Der Robi bleibt dann stehen und wartet auf Beseitigung des Bleches (kann man von Bedienerseite herausnehmen) oder Vakuum aufgebaut.


    Folgendes sollte noch eingebracht werden:

    Anstelle des stehens bei dem zusätzlichen Interrupt soll der Roboter 10mm zurück fahren, seinen Suchwinkel um ca.5° (Foto -> Winkel ) ändern und sich wieder Richtung Endpunkt begeben.


    Problem:

    Ich habe das schon versucht im Interrupt zu lösen. Das klappt mit Relativbewegungen aber nur bedingt. Sobald der Interrupt auslöst, fährt der Robi 10mm zurück, dreht sich um die 5° meldet dann aber eine Störung (weis nicht mehr genau welche das war) und kann den Endpunkt mit seiner veränderten Position nicht anfahren...

    Habt ihr eine Idee wie ich das noch lösen könnte? Es handelt sich um den Interrupt "Anhalten".


    Hier mal ein grober Auszug aus dem aktuellen Quellcode:

    Ich würde mal den SPS.SUB überprüfen.


    Da fehlt manchmal die Abfrage der Statustasten, wieso auch immer:waffen100:.

    Diese kann aber manuell eingefügt werden:

    Code
    ;FOLD GRIPPERTECH LOOP
     GRPg_ChkSetStatePLC()
    ;ENDFOLD (GRIPPERTECH LOOP)


    Einfach mal den Aufruf zur Abfrage der Statustasten im SPS.SUB in dem LOOP einfügen (falls nicht vorhanden!).

    Also kürzester Weg hört sich schon mal gut an, wenn das auch die Achsbewegung betrifft.

    Das eindrehen ist nämlich definitiv mehr Achsbewegung, könnte aber sein, dass es TCP bezogen wenig bis keinen unterschied macht...


    Wie würde das denn in der Syntax aussehen?
    Hab damit noch nie gearbeitet, aber mir gerade mal ein paar Dinge im Forum dazu angeguckt.

    Bekomme da aber nicht so recht den Durchblick. Bin Montag erst wieder an der Anlage und kann was testen.



    Bis dahin würde ich gerne ein paar Möglichkeiten zum "ausprobieren" haben.

    Könntest du mir beispielhaft (grob) sagen, wie so etwas aussehen könnte?


    Mein Beispielprogramm:

    Leider muss ich das Thema doch gerade nochmal aufrollen...


    Ich habe das Problem, dass der Roboter ab Ablegeplatz 7 die Vor- und Nachposition "verdreht" anfahren möchte.

    Er will Achse 4 und Achse 6 verdrehen um auf den Punkt zu kommen. Die alleinige Ablegepos anfahren geht...


    Meine Positionen haben keinen Status und Turn da sie ja durch $NULLFRAME zu einem Frame geworden sind.

    Ich dachte aber, da ich die Ausrichtung der Base aufgrund der teachpositionen ja berechne, sich die Vor- und Nachposition dieser anpassen.


    Folgendes Problem gibt es aber bei der Anlage:

    Zwischen der berechneten Vorposition und Ablegebeposition passiert der Robi eine Achse4/6 Singularität. Genauso bei ablegepos -> nachpos.

    Deswegen werden alle Punkte NUR mit SPTP angefahren.


    Habt ihr Ideen wie ich dem Robi sagen kann, dass er sich die Orientierung/den Status-Turn auch auf die vorposition und nachposition berechnet??


    Könnte den so an die Ablegepos weitergeben, aber wie würde es denn bei den vor und Nachpositionen aussehen? Da ist der S/T ja anders...

    Code
    Xpos1.s = Xposteach.s
    Xpos1.t = Xposteach.t

    Thema kann geschlossen werden!!


    Hat mich gestern noch nerven gekostet... Lösung:


    Irgendwas getestet

    Irgendwas getestet

    Irgendwas getestet

    Steuerung Spannungsfrei 10min

    Neustart

    Fehler besteht weiterhin

    Irgendwas getestet

    Irgendwas getestet

    Irgendwas getestet

    Steuerung Spannungsfrei 20min

    Neustart

    Fehler weg... Es kann wieder alles erstellt werden :wallbash::wallbash:   :uglyhammer_2:

    Hallo alle zusammen,


    mir ist heute an einem unserer KUKAs ein Problem aufgetaucht, was ich bis jetzt noch nicht kannte. Vielleicht könnt ihr mir weiter helfen.


    Das Programm funktioniert ganz normal, kann auch alle Befehle, Bewegung, Logik usw per Inline einbringen AUßER SPTP SLIN und SCIRC.

    Was ist da los? Sobald ich auf "Befehle" drücke, entsprechend "SPTP" aussuche und anklicke passiert gar nichts...

    Genau so bei dem "Bewegung" Button. Sobald ich das mache, habe ich auch eine Zeilenauswahl und nicht mehr diesen Cursor, bzw "Strich" den man zwischen die Wörter setzen kann.


    Außerdem kann ich PTP Bewegungen ändern, SPTP SLIN und SCIRC aber nicht. Da passiert auch wieder nichts...

    Hab ich dann diese "Zeilenauswahl" kann ich auch keine PTP Bewegungen mehr ändern. Ich muss das Unterprogramm schließen und wieder öffnen. Da geht es bei PTP und Logik wieder.


    Es handelt sich um einen KR8 R1620 mit KSS 8.5.6.

    Der Roboter läuft schon länger und am Anfang ging auch alles. Jetzt bin ich gerade nochmal beim Kunden und es geht nicht mehr:cursing:


    Hoffe ihr könnt ihr mir ein paar Tipps geben, die ich mal ausprobieren könnte.


    Vielen Dank schon mal

    Der Robi rennt, vielen Dank für die Hilfe und Erklärungen. Ihr habt mir echt weiter geholfen.


    Anbei noch grob, wie ich das jetzt gelöst habe:


    F_Teachpos = XTeachpos_1


    Da kommt auch die meldung mit nicht initialisierten werten!


    Hab das auch aktuell gerade bei mir gemacht. Probs gibt es da keine....

    Ja, hast du richtig verstanden. Danke nochmal. Mir war nur wichtig Erfahrungen aus der Praxis einzuheimsen:zwink:. Da du das aber auch verwendest und ich es jetzt schon mehrmals gelesen/vorgeschlagen bekommen habe, werde ich das auch so umsetzen.

    Hermann hatte das ja auch schon beschrieben, dass das geht. :supi:

    Erste Frage:
    Wie wandel ich am schönsten und kompaktesten die Teachpositionen in ein FRAME für die spätere Berechnung um?
    Hab im Forum sowas wie das hier gefunden:


    1.) Punkt einfach in Frame schreiben
    XFRAME_=XP1

    "Bei der Verwendung eines Werts vom Typ "E6POS" für einen Parameter vom Typ "Frame" könnten einige Werte nicht richtig initialisiert sein"


    Kann ich den Hinweis der dann kommt ignorieren? Status, Turn und externe Achsen werden hier wahrscheinlich einfach nicht übergeben und deswegen meckert der? Oder könnten im schlimmsten fall irgendwie dadurch auch andere Werte als X,Y,Z,a,b,c übergeben werden?

    2.) Über eine Funktion lösen

    Da schreibe ich ja auch einfach nur mit dem Punktseparator die einzelnen Werte in das Frame rein? Warum als Funktion?

    3. Meine Variante aus den beiden zusammen gebastelt

    Code
    IM .DAT:
    DECL E6POS XTeachpos_1={X 44.6603508,Y 48.8358307,Z -245.740219,A -122.658813,B -89.8507538,C -147.763382,S 2,T 10,E1 0.0,E2 0.0,E3 0.0,E4 0.0,E5 0.0,E6 0.0}
    
    DECL FRAME F_Teachpos
    F_Teachpos ={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0}
    
    
    IM .SRC:
    ;Teachpos in FRAME umwandeln
    F_Teachpos = XTeachpos_1.X.y.z.a.b.c

    Habe so z.B. im .dat meine Teachpunkte, die immer verändert werden könnten und Automatisch sich das Frame anpasst, bei Abarbeitung im .src.

    Kann ich die Teachpos, wie in meinem Teil beschrieben, einfach so in das Frame F_Teachpos schreiben (mit Frame=POS.x.y.z.a.b.c)?


    Könnte dann auch eine Teachpositionen.src erstellen wo alle Positionen Global deklariert sind und die .dat auf Public gestellt wurde.


    Habt ihr eine bessere Idee, oder ist das so Okay?

    Hallo Liebe Robotercommunity,


    erst mal vielen Dank für euer Forum. Ihr habt mir schon oft aus der patsche geholfen und ich konnte mir durch euch sehr oft weiter helfen. Diesmal muss ich aber doch eine Frage stellen, da ich einfach nicht weiter komme. Selbst die Beiträge zu dem Thema helfen mir nicht weiter, oder ich stehe einfach nur auf dem Schlauch:denk:.


    Folgendes ist an der Anlage vorzufinden:

    - Halbrunder Tisch auf dem 10 Bauteilträger montiert sind (Bild siehe Anhang)

    - Bauteilträger zum Ablegen der Bauteile besitzt ca. 30° Steigung (Bild siehe Anhang)

    - Bauteil (Vierkantrohr) mit Flanschplatte (Kann in der Länge auf dem Rohr variieren -> andere Abholpos)


    Folgendes möchte ich gerne einbringen:

    Die Bauteile werden mit dem KUKA von einem Bauteilträger (Bild siehe Anhang) abgeholt und sollen ggf. auf dem Halbrunden Tisch gepuffert werden. Wenn das "Ausförderband" frei ist, können sie auch da abgelegt werden. Das schwierige dabei: Die Bauteilträger sind "schräg" und die Platte auf den Vierkantrohren (=Greifpos) kann in Längsrichtung variieren. Beim Abholen auf dem "Einförderband" und beim Absetzen auf den Tisch muss das also berücksichtigt werden.


    Mein Problem:

    Bei den anderen Robis gab es nur eine Abholpos und eine Ablegepos. Somit konnte ich die BASE mit dem Referenzbauteil auf dem Bauteilträger vermessen und hatte das Koordinatensystem genau wie die Schräge auf dem Träger.
    Dann habe ich das Referenzbauteil mit dem Robi gegriffen, die Ablegepos in dem Bauteilträger geteached und über den Punktseparator und dem "Offsetwert" (SPS: Plattenverschiebung) konnte ich mir alles basteln was ich wollte. Berechnete Vorpos, Nachpos, Ablegepos usw.

    Das ist hier aber nicht mehr möglich, da ich ja die "schräge Basis" nicht mehr habe, bzw ich mir die 10x einmessen müsste!?:wallbash:

    Ich hätte aber gerne eine Basis, wie auf meiner Zeichnung, und von mir aus 10 Teachpunkte mit Referenzbauteil (dann kann man einen Versatz auch einfach mal über teachen anpassen).

    Diese sollten dann entweder eine 2. Base dahin verschieben, oder es läuft iwie über das TOOL Koordinatensystem. Wichtig ist, dass der Punkt BEVOR ich ablege berechnet werden muss, da das Bauteil an einen Anschlag gelegt wird.

    Der Plan ist, beim Wiederaufbau der Anlage, einmal die BASE Tisch neu auszumessen und sofort alle 10 Teachpositionen wieder an Ort und Stelle zu haben.



    Folgendes habe ich schon als Ansatz aus dem Forum:


    Punkt P1 gegeben

    ;1. Verschieben bezügliche Tool-System


    FRAME f

    f=$nullframe

    f.x=100 ; Tool Stossrichtung


    P1=P1:f


    Das Problem, wenn ich mit einem Frame, die X,Y,Z,a,b,c in die ABLEGEPOS schreibe, oder da drauf rechne sind die ja im Bezug zu dem vermessenen Tisch-Kordinatensystem?
    Irgendwie muss ich ja von der/den geteachten Positionen ausgehen um meine Berechnung aufzubauen.

    Habt ihr eine Idee?


    Sorry für den langen Text:roll: