Beiträge von fubini

    Hallo,


    $drive_load abzufragen passiert asynchron, d.h. der Wert dahinter wird nicht zyklisch aktualisiert, sondern nur auf Anfrage, also bei Abfragen der Variable. Somit gibt hier also keine garantierte Antwortzeit, sondern das System aktualisiert wenn es Zeit hat.


    Fubini

    Hallo,


    Zitat

    Kann das $Tool im laufenden Betrieb aufgrund einer Messung verändert werden.


    Du kannst $TOOL jederzeit im Vorlauf ändern.


    Zitat

    Fährt der Roboter die Positionen mit dem $TOOL an und der sichere TCP ist rein für die Geschwindigkeitsberechnung?


    Ja.


    Fubini

    Hallo,


    Zitat

    $TIMER_START[64]=TRUE ; timer anhalten

    sollte eher $TIMER_STOP[64]=TRUE heissen. Ansonsten würde ich auf alle Fälle nach $TIMER[64]=0 und vor $TIMER_STOP[64]=TRUE noch einen Vorlaufstop z.b. über WAIT FOR TRUE einfügen. Ansonsten startet der Timer bereits zu früh im Vorlauf und wird auch zu früh vom Vorlauf wieder beendet.


    Fubini

    Hallo,


    Nein das kann man nicht einfach installieren. Dafür gibt es das (kostenpflichtige) Paket OfficeLite. Da läuft dann eine Steuerung über VmWare auf einer virtuellen Maschine. Die zweite aber im Feld nicht soweit verbreitete Möglichkeit ist ein OPS (OfficeProgrammierSystem) oder oft auch nur OfficePC genannt. Das ist im wesentlichen der PC aus der Steuerung nur ohne den ganzen Rest aus dem Steuerschrank. Das ist auch die genaueste Möglichkeit einen realen Roboter zu simulieren. Daher haben die meisten KUKA Mitarbeiter diese Variante.


    Fubini

    Hallo,


    also KRL ändert sich eigentlich kaum bis gar nicht. Daher verstehe ich nicht ganz was du mit KRL-Version meinst. Ich weiss, dass es bei KRC2 zu KRC4 eingie kleine unterschiede gibt, die sich aber meist gar nicht bemerkbar machen. Ein Programm, dass mal für KRC2 erstellt wurde läuft in aller Regel problemlos auch auf einer KRC4.


    Fubini

    Hallo,


    die KUKA Steuerung und auch jede andere mir bekannte Robotersteuerung plant (Ausnahme bildet hier bei KUKA nur der Splineblock) immer von programmierten Punkt zu programmierten Punkt mit Genauhalt. Es wird also zwischen zwei aufeinanderfolgenden Punkten erst immer so geplant, dass der Roboter am Startpunkt aus dem Stillstand beschleunigt und am Zielpunkt wieder zum Stehen kommt. Etwaiges Überschleifen wird dann erst nachträglich zwischen zwei Bewegungungen, die wie eben gesagt immer mit Geschwindigkeit Null starten und Enden, eingepflegt. Das ist auch notwenidig, so dass der Roboter wenn was schief geht (z.B. Überschleifen nicht möglich) notfalls immer an einem programmierten Zielpunkt anhalten kann. Den von dir angesprochenen zweiten Fall gibt es also nicht, da durch die beschriebene Vorgehensweise immer sicher gestellt wird, dass die Beschleunigung ausreicht. Nachteil ist natürlich, dass man auch mit Überscchleifen nie schneller fahren wird können als durch die Geschwindigkeiten der beteiligten Einzelbewegungen vorgegeben. In der Praxis zeigt sich das am deutlichsten wenn man sehr viele Punkte mit sehr kurzen Punktabständen hintereinander programmiert. In dieser Konstellation kann der Roboter trotz überschleifen nicht auf Geschwindigkeit kommen.


    Hier schafft dann nur der erwähnte Splineblock Abhilfe. Die Steuerung sieht nämlich einen Splineblock mit vielen Segmenten immer noch als eine(!) in sich geschlossene Bewegung an und muss daher das Geschwindigkeitsprofil erst am Ende des Splineblocks und nicht an jeder programmierten Segmentgrenze mit Geschwindigkeit Null enden lassen. Das ist auch einer der vielen Gründe warum man sich bei KUKA für die Einführung des Splineblock entschieden hat. Insbesondere erreicht also der Splineblock auch bei kurzen Punktabständen hohe Geschwindigkeiten.


    Fubini

    Hallo,


    Zitat

    meiner Meinung nach erzeugt jeder Zugriff auf Systemvariablen ($..) einen Vorlaufzeigerstopp

    .


    Das ist sicherlich der Fall, falls eine Hauptlaufvariable beschrieben wird. Aber z.B. $BASE,$TOOL,$VEL, $ACC,$VEL_AXIS,$ACC_AXIS, $APO, $CIRC_TYPE, $ORI_TYPE, ... (zumindest alle Variablen, die die geplanten Bahngeometrien und -geschwindigkeiten beeinflussen) schreiben alle die entsprechenden Daten für den Vorlauf, da die Bahnen/Trajektorien im Vorlauf geplant werden. Also wo sollte da der Sinn sein, einen Vorlaufstopp auszulösen. Es gibt wahrscheinlich eher wenige Variablen die Vorlaufstopp auslösen, allerdings kommt es einem immer anders vor, da bei den Vorlaufstoppenden einige der am meisten verwendeten dabei sind.


    Gruß,
    Fubini

    Hi,


    was kommen denn in T2 für Meldungen bei gesetztem $STOPNOAPROX = TRUE.


    Die Continues braucht es sicher nicht und bei zu großem Überschleifkriterium kappt die Steuerung einfach auf Satzmitte, d.h. es wird mit maximalen und nicht mit minimalen Radius überschliffen.


    Ansonsten kann ich diese Post und die Links darin empfehlen. Da wird einiges zum Überschleifen diskutiert:
    http://www.roboterforum.de/rob…n/12894/msg62211#msg62211



    Zitat

    Übernimmt die Steuerung für die Relativbewegung die Geschwindigkeit & Beschleunigung der vorhergehenden Bewegung (P1) ?


    Ja. Solange man nichts anderes sagt werden die Werte immer beibehalten. Einzige Ausnahme dazu sind Segmente innerhalb eines Splineblocks.


    Zitat

    Wie kann ich diese für die Relativbewegung verändern ?


    $VEL_AXIS[1-6], $ACC_AXIS[1-6], $VEL_EXTAX[1-6], $ACC_EXTAX[1-6] oder für Schreibfaule BAS(#PTP_PARAMS, 80) setzt nur die Geschwindigkeiten auf 80% oder für nicht ganz so Schreibfaule VEL_PTP(80) und ACC_PTP(75) setzen Geschwindigkeit auf 80% und Beschleunigung auf 75% (einfach mal in bas.src schauen was bei BAS(#PTP_PARAMS) so alles passiert).

    Hallo,


    was für einen Wert hat den $SPL_VEL_MODE. Existiert die Variable in deiner Software überhaupt schon? Falls nicht wird der Spline in seinem Geschwindigkeitsverhalten über $VEL, $ACC, $JERK programmiert. Falls die Variable schon existiert gibt es zwei Modi: #CART oder #OPT.


    Bei $SPL_VEL_MODE = #CART wird das Splineprofil weiterhin über $VEL, $ACC programmiert. Es ist also bis auf $JERK genauso zu programmieren wie bei alten LIN und CIRC Bewegungen.


    Bei $SPL_VEL_MODE = #OPT ist das anders, da dann das Dynamikmodell für das Splineprofil angewendet wird. Hier muss dann analog zum alten PTP über $VEL_AXIS[], $ACC_AXIS[] programmiert werden. Zusätzlich kommt nur noch $VEL.CP dazu. Ferner ist hier wie bei PTP darauf zu achten, dass auch korrekte Lastdaten gesetzt sind.


    Ansonsten fällt mir ohne Speicherabzug dazu auch nicht mehr viel ein.


    Fubini

    Hallo,


    versuch doch mal einfach dein Programm nicht Spline zu nennen sondern irgendwie anders. Also statt


    DEF SPLINE()


    in der ersten Zeile


    DEF MYSPLINE()


    und denke dann auch daran den Filenamen analog zu ändern. ICh vermute mal stark für KRL ist SPLINE ein geschütztes Keyword, das den Beginn eines Splineblocks kennzeichnet. Da ist übrigens nicht KRL zu doof, sondern das gibt es in allen anderen Programmiersprachen genauso. Man wird auch in C keine Routinen anlegen können, die z.B. for heißen, da man dann den Compiler mit der for-Schleife durcheinander bringen würde.


    Fubini

    Hallo,


    die Steuerung muss im Echtzeitbereich unter VxWorks bestimmte Aufgaben in bestimmen Zeitscheiben zyklisch erledigen (z.B. Abbild der Ein- und Ausgänge aktualisieren, Positionen aufbereiten, ...). Schafft die Steuerung es einmal nicht diesen Grundtakt der Zeitscheiben einzuhalten kommt eine Interpolationstaktzeitüberwachung, d.h. die Einhaltung der Zeitfenster wird über Watchdogs überwacht. Das läuft dann also in etwa so ab: Aufgabe A muss alle 12 ms erledigt sein, da aber Aufgabe B die ganze Rechenzeit verbrät kommt A nie dran seinen Job zu erledigen. Und schon schepperts. Die Rolle von A spielem bei dir die Aufgaben, die in ZYK_postIPO abgearbeitet werden müssen.


    Was jetzt der konkrete Grund für deinen Fall war lässt sich leider nicht so pauschal sagen, kann aber von KUKA anhand eines KRCDiags, erstellt am besten während die Meldung ansteht, näher untersucht werden.


    Das Auftreten solcher Probleme hängt also massiv von der Rechenbelastung der Steuerung ab, und das hängt dann natürlich auch wieder davon ab was die Steuerung alles erledigen muss. Das kann jetzt aber wiederum auch durch den Nutzer (z.B. durch Technologiepakete) beeinflusst werden.


    Fubini