Frage zu dem : Operant mit Turn und Status

  • Hallo Zusammen,
    ich habe eine Frage zu Turn und Status in einer Position. Was passiert damit wenn man den : Operant verwedent?
    Ich habe eine Funktion geschrieben das mir Offsetwerte erlaubt.
    Zum Beispiel so:


    $APO.CPTP=100
    BAS(#VEL_PTP,100)
    BAS(#TOOL,2)
    BAS(#BASE,0)
    PTP PosOffs(XPufferLinks,{X 400,Y -100,Z 200},#BASE) C_PTP


    $APO.CPTP=100
    BAS(#VEL_PTP,100)
    BAS(#TOOL,2)
    BAS(#BASE,0)
    PTP PosOffs(XPufferLinks,{Y -100,Z 180},#BASE) C_PTP


    $APO.CPTP=100
    BAS(#VEL_PTP,100)
    BAS(#TOOL,2)
    BAS(#BASE,0)
    PTP PosOffs(XPufferLinks,{Z 170},#BASE) C_PTP


    $APO.CPTP=50
    BAS(#VEL_PTP,100)
    BAS(#TOOL,2)
    BAS(#BASE,0)
    PTP PosOffs(XPufferLinks,{Z 50},#BASE) C_PTP


    ;FOLD LIN PufferLinks Vel= 0.5 m/s CPDAT3 Tool[2]:Grf Schmutzig Base[0];%{PE}%R 5.4.35,%MKUKATPBASIS,%CMOVE,%VLIN,%P 1:LIN, 2:PufferLinks, 3:, 5:0.5, 7:CPDAT3
    $BWDSTART=FALSE
    LDAT_ACT=LCPDAT3
    FDAT_ACT=FPufferLinks
    BAS(#CP_PARAMS,0.5)
    LIN XPufferLinks
    ;ENDFOLD



    Hier die Funktion PosOffs


    &ACCESS RO1
    &REL 1
    &COMMENT positionsoffset
    &PARAM TEMPLATE = C:\KRC\Roboter\Template\vorgabe
    &PARAM EDITMASK = *
    DEFFCT E6POS PosOffs(RefPos :IN,Offset :OUT,OffsMode :IN)
    DECL E6POS RefPos,NewPos
    DECL FRAME Offset
    ;Typ in Config.dat mögliche werte:NONE,TCP,BASE
    ;damit wird die verschiebung relativ zum tool oder zur
    ;base (aktive base) berechnet
    DECL IPO_M_T OffsMode


    ;abfragen welche übergabeparameter angegeben wurden
    ;wenn ein parameter fehlt wird dieses argument mit
    ;null initialisiert
    IF VARSTATE("Offset.x")<>#INITIALIZED THEN
    Offset.x=0.0
    ENDIF
    IF VARSTATE("Offset.y")<>#INITIALIZED THEN
    Offset.y=0.0
    ENDIF
    IF VARSTATE("Offset.z")<>#INITIALIZED THEN
    Offset.z=0.0
    ENDIF
    IF VARSTATE("Offset.a")<>#INITIALIZED THEN
    Offset.a=0.0
    ENDIF
    IF VARSTATE("Offset.b")<>#INITIALIZED THEN
    Offset.b=0.0
    ENDIF
    IF VARSTATE("Offset.c")<>#INITIALIZED THEN
    Offset.c=0.0
    ENDIF
    IF (OffsMode==#TCP) THEN
    ;verschiebung in toolkoordinaten
    RETURN (RefPos:Offset)
    ELSE
    ;verschiebung in basekoordinaten
    NewPos=Offset:RefPos
    ;RETURN (Offset:RefPos)
    RETURN (NewPos)
    ENDIF
    ENDFCT


    So weit so gut. In den meisten Fällen funktioniert die Funktion wie sie funktionieren soll. Und manchmal wenn ich zum Beispiel einen Offset von 100 mm in Z eintrage kommt da eine Meldung das die Position nicht erreicht werden kann wegen einem Softwareendschalter. Wenn ich aber von Hand 100 mm linear von der Referenzposition fahre ist der Roboter locker von allen Softwareendschalter entfernt. Dann trage ich einen kleineren Wert ein (90 mm) und der Roboter arbeitet das Programm ab wie es sein soll.
    Meine Vermutung ist jetzt das der Status und Turn auch noch bei dieser Operation verändert wird. Kann das sein? :nocheck:
    Diese Funktion benutze ich schon länger und geht über verschiedene Softwarestände.
    Wäre super wenn mir da einer helfen kann.
    Gruß Paulaner

    Für seine Arbeit muß man Zustimmung suchen, aber niemals Beifall.<br />Zitat: Charles-Louis Baron de Montesquieu

  • Schritt für Schritt zum Roboterprofi!
  • Hallo Paulaner,


    würde es funktionieren wenn du die Variable "NewPos"
    als FRAME deklarierst anstatt als E6POS ?


    Gruß
    Twister

    Kleinere Wunder werden sofort erledigt... größere nach der Mittagspause...

  • Ja, das kann daran liegen.
    Es kann sein, dass durch die Verschiebung eine Vorzeichenänderung einer Achse nötig wär. Wenn Du die nicht erlaubst kommt der Softwareendschalter.


    Abhilfe: (wie schon erwähnt)
    Statt E6Pos mit Frame arbeiten.
    Aber Vorsicht! Es kann dann sein, dass der Roboter die Position in einer ungewünschten Konfiguration anfährt. (Bei ptp, bei Lin kann er eh nicht aus, da ist ja Status und Turn egal.)

  • Willkommen in der KUKA-Welt. :uglyhammer_2:
    Ja so ist das mit Status und Turn.
    Verwende anstatt eine POS oder E6POS-Variable eine FRAME-Variable dann geht es.
    Aber Vorsicht!!!!!! Sollte der Roboter meinen das er bei der Bewegung zu einer Position eine 340 Grad Drehung machen zu müssen kurbelt er wie ein Helikopter durch Deine Applikation.!!!! :wallbash:
    Ist abhängig von der Stellung Achse 5 positiv oder negativ. Sollte der Roboter während der Palettierung durch die Singularität gehen wird er Dir einen Hubschrauber machen.


    Habe ich mit jeweiligen geteachten Zwischenpositionen, welche ich positionsabhängig aufrufe gelöst. Ist aber bei über 624 Teilen ein blödes Spiel.


    Gruß


    Sven

    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!

  • Hi Twister,
    das werde ich mal ausprobieren. Hab die NewPos noch nicht als Frame ausprobiert. Im Frame ist kein Turn und Status enthalten mal schauen wie der Roboter sich dann bewegt.
    Probieren geht über studieren..........

    Für seine Arbeit muß man Zustimmung suchen, aber niemals Beifall.<br />Zitat: Charles-Louis Baron de Montesquieu

  • ... den Hubschrauber find ich Klasse ...
    ... so langs nicht meine Anlage ist ... :lol:
    Nen ganz bösen Hubschrauber macht er wenn die
    Achse A1 am Ende ist und er versucht die Position
    von der anderen Seite anzufahren im PTP ;)

    Kleinere Wunder werden sofort erledigt... größere nach der Mittagspause...

    Einmal editiert, zuletzt von Twister ()

  • Der Robi soll ja gerade nicht den Helikopter spielen. :uglyhammer_2:
    Es gibt da noch ein Programm von Kuka das immer irgendwo abgelegt ist. Irgendwas mit dem "kürzesten Weg" zwischen zwei Punkten. In diesem Programm wird mit S und T gearbeitet. Leider habe ich es gerade nicht zur Hand. Das könnte man noch dazischenklemmen?
    Hat das schon einer verwendet?

    Für seine Arbeit muß man Zustimmung suchen, aber niemals Beifall.<br />Zitat: Charles-Louis Baron de Montesquieu

  • Oder vielleicht, wenn es die Taktzeit erlaubt, kannst ja
    grob im PTP vorpositionieren und den Rest im LIN fahren.
    Dann dürftest keine Hubschrauberaktionen erwarten.

    Kleinere Wunder werden sofort erledigt... größere nach der Mittagspause...

  • Wäre halt schön wenn diese Funktion immer 100%tig funktioniert. Egal wie T und S gerade sind. Der Robi soll einfach nicht irgendeine Achse unnötig drehen.
    Ich hab noch diese Programme von Kuka gefunden. Die habe ich hier angehängt. Das könnte was sein was hilft. Aber da muss ich mich auch erst mal schlau machen was da genau passiert.
    In der Textdatei wird das gewünschte verhalten schon mal beschrieben.

  • Guten Morgen Zusammen,
    Mir ist noch was eingefallen. Wenn manchmal dieses Problem mit den Softwareendschalter auftrat habe ich ja den Robi von Hand in die gewünschte Position bewegt. Dabei habe ich mir das Positionsfenster angeschaut und keinerlei Veränderung an Turn und Status festgestellt.
    Also:
    PTP-Bewegung mit Offset 100 mm --> erzeugt eine Fehlermeldung. Die Position kann nicht erreicht werden wegen einen Softwareendschalter.
    Wenn ich nun von Hand den Roboter 100 mm (oder auch mehr!) bewege, passiert nichts. Es werden keine Softwareendschalter aktiviert. Laut Positionsfenster ändert sich Turn und Status auch nicht. Fragen über Fragen :denk:
    Könnte ich in der Funktion noch zusätzlich nach dem die neue Position mit dem : Operant berechnet wurde, Turn und Status mit den Werten von der RefPos überschreiben?
    Das werde ich mal bei der nächsten Gelegenheit ausprobieren.

    Für seine Arbeit muß man Zustimmung suchen, aber niemals Beifall.<br />Zitat: Charles-Louis Baron de Montesquieu

  • Hallo Paulaner,


    du musst berücksichtigen dass du den Roboter von "Hand" immer
    in einer LIN-Bewegung verfährst, nie in einer PTP-Bewegung in
    mehreren Achsen auf einen Zielpunkt.
    Du kannst die PTP-Programmbewegung im Handbetrieb nicht nachstellen.


    Gruß
    Twister

    Kleinere Wunder werden sofort erledigt... größere nach der Mittagspause...

    Einmal editiert, zuletzt von Twister ()

  • Ja das ist mir auch klar. Ich bin mir nicht mehr ganz so sicher wann diese Fehlermeldungen auftauchten. Nur bei PTP oder nur bei LIN oder bei beiden.
    Ich muss mal das Ganze genauer überprüfen, wenn sich die Möglichkeit ergibt.
    Also diese Programme von Kuka "Kue_Weg"....ich weiß nicht so recht. Davon lass ich erst mal die Finger weg.
    Bei dem nächsten Fehler werde ich mir den Rückgabewert abspeichern und anzeigen lassen. Dann weiß ich mehr.

    Für seine Arbeit muß man Zustimmung suchen, aber niemals Beifall.<br />Zitat: Charles-Louis Baron de Montesquieu

  • Bei Lin prüft der Roboter vorher nach, ob er überhaupt zu der Position fahren kann. Geht auch, da der Weg der Linbewegung vorher schon bekannt und berechnet werden kann.
    Bei PTP fährt er den kürzesten/schnellste Weg. Damit ist der kürzeste Weg für die Achsen gemeint.
    Da kann es dann schnell passieren, dass der Roboter erst bei der Fahrt merkt, dass das was er vorhat nicht klappt.
    Theoretisch kann die PTP Fahrt auch jedesmal anders ablaufen.
    Tut sie nicht oder so minimal, dass man es nicht sieht, da ja der Start und Endpunkt immer gleich sind.
    Daher passiert es auch schnell, dass man sich wundert, wieso der Roboter per Hand an eine Stellung gut fahren kann, es aber in Automatik plötzlich nicht mehr geht.

  • Das macht der Robi ja gerade nicht. Bei der PTP-Bewegung soll er den kürzesten Weg (von den Achsen aus gesehen) nehmen aber bei der Offset-Funktion mit dem : Operant passiert irgendwas. Meine Vermutung ist das sich TURN und STATUS ändern. Aber warum?
    Wenn ich den Robi von Hand in diesem besagten kritischen Bereich verfahre ist alles Ok. Also keine Softwareendschalten am Limit. Turn und Status ändern sich auch nicht. Robi steht relativ gut da.. :supi: also nicht nahe an einer Singularität.
    Gruß Paulaner

    Für seine Arbeit muß man Zustimmung suchen, aber niemals Beifall.<br />Zitat: Charles-Louis Baron de Montesquieu

  • Hi,
    meine Erfahrung nach ist PTP nicht zwanghaft der kürzer Weg!
    Die Meldung von wegen Achslimit ist ein Softwarebug seitens KUKA! ^^
    Bei meinen Applikationen ist dies auch so gewesen. Offset errechnen lassen und losfahren.
    War bei PTP nicht möglich wegen Status und Turn. Änderst Du auf LIN kannst Du den Punkt anfahren. So wars bei mir. LIN ist aber nicht taktzeitoptimal also PTP-Pflicht.
    Da bei LIN teilweise auch die Achsgeschwindigkeit Achse 4 zu hoch ist. Steuerung bekommt das nicht geregelt. KUKA halt.
    Also fahre ich nur noch PTP mit einer FRAME-Variablen. So bevor ich diese Position aber anfahre kann es durch ein durchfahren des Nullpunktes der Achse 5 dazu kommen das der Roboter eben mal nicht den kürzesten Weg nimmt sondern meint die Achse 6 umher drehen zu müssen. KUKA-Hubschrauber halt. :uglyhammer_2:


    Daraus schlussfolgere ich einfach mal das PTP nicht zwanghaft der kürzere Weg ist.


    PTP heißt eigentlich nur das alle Achsen gleichzeitig sich beginnen zu bewegen und auch gleichzeitig wieder in dem Zielpunkt zum halt kommen. Wie dies in der Regelung priorisiert ist sagt keiner.



    Gruß


    Sven

    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!


  • Hi,
    meine Erfahrung nach ist PTP nicht zwanghaft der kürzer Weg!


    Gruß


    Sven


    Ist auch nicht so. PTP ist im Normalfall nicht der kürzere sondern der schnellere Weg.



    Daß bei Arbeiten mit Offsetwerten (z.B. bei Palettierungen) bei Kuka der Turn gewechselt werden muss, zumindest soweit ich das aus eigener Erfahrung mitbekommen habe, ist doch eigentlich schon ein alter Hut.
    Ich kenne das gar nicht anders.

    Gruß Roland


    Wie poste ich falsch?

    Nachdem ich die Suche und die FAQ erfolgreich ignoriert habe, erstelle ich das gleiche Thema in mehreren Unterforen, benutze einen sehr kreativen Titel wie "Hilfe", am Besten noch mit mehreren Ausrufezeichen, und veröffentliche einen so eindeutigen Text, dass sich jeder etwas Anderes darunter vorstellt.


    Ich bin wie ich bin. Die Einen kennen mich, die Anderen können mich.

    Konrad Adenauer

  • Richtig denn der kürzeste Weg zwischen zwei Punkten ist eine Gerade! Geometrie 6. Klasse. :biggrins:


    Gruß


    Sven

    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!

  • Aber nicht, wenn man die kürzesten Weg jeder Achse nimmt. Dann kommt ein Bogen raus.
    Wie es KUKA genau macht weiss ich net, aber im Studium wurde es so erklärt:
    Es wird der Endpunkt in Achswinkel umgerechnet, dann fährt jede Achse auf diesen Wert.
    Da die Achsen aber von +-180 Grad gehen, kann es da schnell so Rechenproblemen kommen.
    Und das sind dann die Geschichten mit Achse macht Hubschrauber. Der Roboter sieht ja nicht, wie rum es kürzer wäre.


    mal ein Beispiel: Start Achse ist bei 90 Grad Endachse soll aber bei -90 Grad sein. Wie rum soll er jetzt die Achse drehen links rum oder rechts rum.
    In dem Beispiel ist es egal, aber wenn man andere Winkel nimmt und dann noch die Stellung aller Achsen einbezieht, wird ja schell klar, wie schwer sowas wird.

  • Joo hast recht! :zwink:


    Aber andere Roboterhersteller haben das Problem besser im Griff. Naja kann man nix machen.


    Gruß


    Sven

    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!

  • Hallo Zusammen,
    ist ein schwieriges Thema wie es aussieht :genau:
    Also irgendwie schweifen wir von meinem Problem ab. Glaube ich mal!


    @dos6.22
    Solche Probleme die du beschreibst und auch logisch sind werden mit Turn und Status in einer Position erledigt. Darin stehen ja die Werte wie die Achsen bei der Position stehen sollen.
    Also kann der Robi nur so die Achsen drehen wie sie mit T und S angegeben sind.


    Sven Weyer
    Ja andere Hersteller haben komischerweise keine Probleme damit. Ich sag nur Offs oder RelTool......


    Was passiert mit T und S beim dem : Operant :waffen100:


    Wenn ich eine Referenzposition habe bei der alles Ok ist. An dieser Position ist der Greifer geöffnet und der Robi kann einfach nach "oben" fahren.Und jetzt verwende ich die am Anfang erwähnte Funktion.


    PTP PosOffs(XPufferLinks,{Z 170},#BASE) C_PTP


    dann kommt die Fehlermeldung mit dem Softwareensschalter. Ändere ich nun die Zeile um.. so etwa


    PTP PosOffs(XPufferLinks,{Z 150},#BASE) C_PTP


    geht alles!
    Wenn ich den Robi von dieser Position aus (Z=150) von Hand auf die 170 mm bewege sieht alles in Ordnung aus. Die Achse 4,5 und 6 bewegen sich nicht mal viel. Die größten Bewegungen machen die Hauptachsen. Bei der Positionanzeige ändern sich T und S auch nicht.
    Also muss doch bei der Berechnung
    NewPos=Offset:RefPos
    irgendwas passieren was ich nicht ganz verstehe.
    Wenn ich sowas programmiere
    PTP {X -1293.20398,Y 785.216187,Z 491.908112,A 89.2432938,B -0.0642487183,C -0.0885750279,S 6,T 19,E1 0.0,E2 0.0,E3 0.0,E4 0.0,E5 0.0,E6 0.0} : {X 0,Y 0,Z 200}
    wird wie es aussieht nicht nur die 200 mm auf Z addiert sondern auch je nach Bedarf T und/oder S geändert. Aber bei meinem Fall hätte der Robi eindeutig den längeren Weg genommen. Eine Achse hätte sich bestimmt 180 Grad gedreht. Das hätte nicht sein müssen.
    Prost Mahlzeit. :uglyhammer_2:

    Für seine Arbeit muß man Zustimmung suchen, aber niemals Beifall.<br />Zitat: Charles-Louis Baron de Montesquieu

    Einmal editiert, zuletzt von titan72 ()

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