Beiträge von fubini

    Hallo,


    bei dir, d.h.
    AXIS_CHECK_LIM =INVERSE (POSITION, START_AXIS, Fehlernummer)
    musst du natürlich auf Fehlernummer schauen, das ist ja die Variable die du an INVERSE übergibst.


    Nochmal zur Klarstellung der dritte Parameter in INVERSE, d.h. bei dir Fehlernummer, wird sowohl als Eingabe- als auch als Ausgabewert verwendet. Es ist also einerseits wichtig welchen Wert er direkt vor Aufruf von INVERSE hat, um festzulegen wie INVERSE mit Softwareendschaltern umgehen soll:
    Bit 0=0: Alle Achswinkel werden geprüft, ob sie innerhalb der SW-Endschaltergrenzen liegen. Wenn nicht, dann wird über ERR_STATUS bzw. bei dir Fehlernummer ein entsprechender Fehlercode zurück geliefert.
    Bei Bit 0 = 1 wird dementsprechend kein Prüfung der Endschalter gemacht.


    Ist man durch INVERSE durch enthält Fehlernummer die Rückmeldung ob und was schief gegangen ist, falls ein Wert kleiner Null drin steht. Diese Fehlercodes hast du ja bereits selbst aufgeführt.


    Also Fehlercode -2 bedeutet: beim Aufruf von INVERSE hatte Fehlernummer noch keinen gültigen Wert, war also wahrscheinlich nur deklariert aber nicht initialisiert. Daher würde ich mal direkt vor dem Aufruf von INVERSE Fehlernummer den Wert 0 oder 1 zuweisen je nachdem ob du die Endschalterprüfung haben willst oder nicht.


    Fubini

    Hallo Joschy,


    ja INVERSE rechnet eine kartesische Position (X,Y,Z,A,B,C, ...) in Achswerte (A1, A2, A3, ...) um. Allerdings reichen für Eindeutigkeit nicht (X,Y,Z,A,B,C) alleine aus. Daher ist es auch noch notwendig Status (S) und Turn (T) zu betrachten. Konkret gibt es zu jeder kartesischen Position theoretisch bis zu 8 verschiedene Achsstellungen, d.h. unterschiedliche Stati, die alle die gleichen kartesischen (X,Y,Z,A,B,C)-Werte haben. Die Inverse stellt nun mehrere Varianten zur Verfügung wie man aus diesen theoretisch 8 möglichen Achsstellungen wählen will. Direkte Statusübergabe, kütrzester Abstand zu einer gegebenen Achsstellung. Welche Variante man will wählt man über den ERR_STATUS als Input in die INVERSE()-Funktion und $TARGET_STATUS festgelegt.


    Ferner muss man im Hinterkopf die Bewegungsart haben und Wissen wie diese mit Status und Turn umgehen:
    http://www.robot-forum.com/rob…riable/msg67275/#msg67275
    Leider scheint der darin eingebettete Link
    http://www.robot-forum.com/rob…-(-s-)/msg33467/#msg33467
    der das genauer erkläret nicht mehr zu funktionieren (Admin ->?)
    Fubini

    Hallo,


    zumindest bei den zylindrischen Arbeitsräumen kann man über REFERENCE = #WORLD oder #ROBROOT (=Roboterfuß) wählen wie das Bezugssystem liegt. Bei #ROBROOT würde dann bei Robotern auf Lineareinheit der Raum mit dem Roboter mitfahren. Bei den $WORKSPACES gibt es dass meines Wissens nach nicht. Hier kannst du aber die Grenzen im Programm setzen. Das wirkt dann in der KRC4 im Hauptlauf, also sofort. Früher war das mal Vorlauf. Nachdem du nichts zu deiner Softwareversions sagst geht's nicht genauer.
    Ansonsten gäbe es noch die Option SafeOperation, da kannst du ähnlich wie bei den zylindrischen Arbeitsräumen das Bezugssystem auch fest in der Welt oder in den Roboterfuß legen.


    Fubini

    Hallo


    Dein eigentliches Problem hat wahrscheinlich nichts mit der SAK-Fahrt zu tun, sondern, dass $BASE und $TOOL noch ungültig sind und damit auch $POS_ACT. Daher würde ich im Submit immer auf Gültigkeit (siehe VARSTATE Funktion) der beiden prüfen.


    Fubini

    Nr 1030 ist ein Sensorfehler? Leider gibst du viel zu wenig Information um mehr zu sagen. KRC Version? Robotertyp? Die Meldung hat bis zu drei Parameter. Welche? Was macht ihr gerade wenn der Fehler kommt? Welche Sensorik setzt ihr ein? ...


    Fubini

    Hallo,
    den Speicher zu leeren geht nicht.
    Man könnte aber versuchen sich mehr Speicher zu verschaffen. Z.B. merkt sich das System um über "Start-" rückwärts fahren zu können eine bestimme Anzahl an Bewegungen, wobei ein Splineblock als eine Bewegung zählt. Ich glaube im Defaultfall sind das 30 Bewegungen. Falls du nie mit "Start-" rückwärts fahren willst, könnte man da auch Null reinschreiben. Du sagst leider nichts über deine Softwareversion. Wie man das einstellt ist aber leider versionsabhängig.
    Oft hilft der Trick lange Splineblöcke durch Überschleifen in kleinere zu zerteilen. Damit ist jede einzelne Splinebewegung nicht so lang und man braucht aufgrund des Vorlaufs nicht mehr so viel Speicher.
    Fubini

    Gut in dem Fall wäre noch wichtig:
    Sind Status und Turn bei der kartesischen Eingabe "zuPrüfenderPunkt" gesetzt oder ungültig? Sind die gesetzt werden sie auch verwendet. Anderenfalls müsstest du Bit 6 im Eingabewert "Fehler" setzen, damit der Status nicht verwendet wird und alle Stati durchprobiert werden und der mit kürzestem Weg zu "XHOME" gewählt wird. Analoges gilt auch für den Turn.
    Ach ja: $TOOL und $BASE sind auch die gleichen beim INVERSE() Aufruf und dem Später angefahrenen Punkt?


    Noch zur Erklärung für dich:
    Arbeitsraumfehler bedeutet zu dem verwendeten Status gibt es keine Achswinkel, d.h. die Inverse Transformation ist nicht lösbar.
    Softwareendschalter bedeutet es handelt sich um ein Turn-Problem, d.h. mit dem verwendeten Turn landet man hinter dem Softwareendschalter. Mit einem anderen Turn würde es aber vielleicht klappen.


    Fubini

    Hallo,
    [list type=decimal]

    • Was heißt nicht anfahrbar? Fährst du z.B. in einen Softwareendschalter?

    • Bei welchen Bewegungstypen passiert, dass du die Posen nicht anfahren kannst? Nur bei PTPs oder auch bei CPs (LIN oder CIRC)

    [/list]
    Fubini

    Hallo,
    Ohne Gewähr: In C:\KRC\ROBOTER\Config\System\Common\ConfigXML.xml den Eintrag
    <Environment EnvPath="Cabinet/"/> ändern in <Environment EnvPath="Office/"/>
    Kaltstart mit Dateien neu einlesen nicht vergessen.
    Fubini

    Hallo Twister,


    es gibt keine Möglichkeit die Genauigkeit zu erhöhen. Das langsamer Fahren ist ja gerade $CP_VEL_TYPE.


    Gruß
    Fubini

    Hallo,
    ist der Roboter absolutgenau? Das "schwänzeln" kommt dann wahrscheinlich davon. Wenn du also keine Absolutgenauigkeit brauchst am besten abschalten.
    Ansonsten ist der Unterschied zwischen VAR_ALL_MODEL und VAR_ALL nur, dass bei VAR_ALL_MODEL das Dynamikmodell befragt wie stark die Achsen durch $CP_VEL_TYPE verzögern können. Bei VAR_ALL gelten für die Achsen andere fest Rampen. Bei $CP_VEL_TYPE = VAR_ALL_MODEL ist das Verhalten also insbesondere stellungsabhängig und lastabhängig.


    Fubini

    Hallo,


    Der Wert $COULD_START_MOTION gibt an, ob ein Programmstart oder Handverfahren intern möglich wäre.


    Möglich bedeutet, dass keine verriegelnden Meldungen mehr anstehen, die aktive Kommandos verriegeln.


    Ist die Variable FALSE würde ein drücken der Starttaste oder ein Handverfahrbefehl ggf. mit


    der Meldung 1376: "Aktive Kommandos verriegelt" abgelehnt, falls nicht bereits andere Gründe dies verhindern


    (wie z.B. wenn kein Programm angewählt ist oder man sich fürs Handverfahren nicht in T1 befindet)


    Die Variable ist für die HMI eingeführt worden, damit diese in der Anzeige durch


    eine farbliche Hervorhebung darstellen kann, dass alles OK ist und einem Start nichts mehr


    entgegensteht.


    Theoretisch wäre es denkbar, dass die Information auch für eine SPS interessant wäre.


    Dies würde es nahelegen, statt einer einfachen Systemvariable ein Signal einzuführen.


    Wegen der suboptimalen Realisierung der FALSE-Rangierung hätte dies aber den unangenehmen Effekt,


    dass bei entsprechender Rangierung auf FALSE die HMI Handverfahren komplett


    blockiert und die Anzeige immer suggeriert, dass nicht gefahren werden kann. Daher wurde


    $COULD_START_MOTION als einfache Boolesche Variable eingerichtet.


    Die HMI ist angehalten, ggf. durch "greyen" von entsprechenden Tasten


    die entsprechenden Bedienhandlungen erst gar nicht anzubieten.


    Der Wert sagt nichts darüber aus, ob gerade aktive Kommandos in Bearbeitung sind.


    Der Wert sagt nichts darüber aus, ob gerade ein Programm angewählt ist.




    Fubini

    Hallo,
    Unis haben ja oft Matlab. Da könnte ich die freie Robotics Toolbox von Corke empfehlen. Damit kannst du auch inverse Kinematik rechnen. So weit ich weiß ist da als Beispiel der Puma enthalten, der kinematisch identisch zum KUKA 6-Achser ist. In der Literatur wird diese Form von Kinematik auch oft als Stanford Manipulator bezeichnet. Darüber sollte sich auch noch mehr finden lassen.
    http://petercorke.com/Robotics_Toolbox.html
    Fubini

    Hallo,


    versuch doch mal


    BOOL StrComp (CHAR strComp1[470] :IN, CHAR strComp2[470] :IN, CASE_SENSE_T CaseSens :IN)


    strComp1 - string to compare with strComp2
    strComp2 - string to compare with strComp1
    CaseSens - case sensitive or not (#CASE_SENS, #NOT_CASE_SENS)
    return value - Returns TRUE if the strings are equal


    Examples:
    StrComp ("ABC”, "ABC”, (#CASE_SENS)) ? =>TRUE
    StrComp ("ABC”, "abc”, (#NOT_CASE_SENS)) =>TRUE
    StrComp ("ABC”, "abc”, (#CASE_SENS)) => FALSE
    StrComp ("ABC”, "acb”, (#NOT_CASE_SENS)) =>FALSE


    siehe 11.15.6 Inhalt von Stringvariablen vergleichen in der "KUKA System Software 8.3 Bedien- und Programmieranleitung für Systemintegratoren"


    Fubini

    Hallo,


    bitte immer direkt nach der Deklaration die Initialisierungen:


    DECL GLOBAL REAL Achswinkel_1[6]
    Achswinkel_1[1]=0
    Achswinkel_1[2]=0
    Achswinkel_1[3]=0
    Achswinkel_1[4]=0
    Achswinkel_1[5]=0
    Achswinkel_1[6]=0


    DECL GLOBAL REAL Position_1[6]
    Position_1[1]=0
    Position_1[2]=0
    Position_1[3]=0
    Position_1[4]=0
    Position_1[5]=0
    Position_1[6]=0


    dann sollte es gehen.


    Fubini