Beiträge von fubini

    Ja die braucht es. Da gibt es keine explizite Doku dafür. Im Endeffekt verbirgt sich da eine Rechteverwaltung auf Dateiebene dahinter ähnlich wie in Unixbasierten Dateisystemen. Es werden über diese Werte also so Dinge wie Leserechte, Schreibrechte, ... vom System verwaltet. Man kann auf der HMI zum Teil auch Dateiattribute wie z.B. sichtbar ändern. Das spiegelt sich dann auch darin wieder.


    Fubini

    Wo kann ich Informationen zum "Funktionsgenerator" finden?

    Viele KUKA Technologien basieren unter der Haube darauf. Ist aber nicht Teil der offiziellen Kundenschnittstellen. Es gibt aber Leute die durch Reverse-Engineering da viel rausgefunden haben. Also entweder Suchfunktion hier im Forum oder auch im englischen Partnerforum bemühen und auch mal im Kuka XPert Webportal vorbeischauen.


    Fubini

    SafeOperation? Dann $SR_VRED wenn ich mich richtig erinnere. Kann mich täuschen ich glaub aber in der SafeOperation Doku sind die alle beschrieben.


    Fubini

    tZYK_postIPO ist der Name einer VxWorks Task im Echtzeitbetriebssystem des Roboters , die ihr Zeitfenster verletzt hat. Was Ursache ist ist so einfach nicht zu sagen. Es heißt soviel wie diese Tasks ist nicht drangekommen ob wohl sie was hätte machen müssen, sprich sie wurde durch eine andere verdrängt. Ursache liegt also in einer anderen Task, die zu viel Rechenzeit verbraucht hat. Am besten KRCDiag im Fehlerfall erstellen und an KUKA senden, Die notwendige Info um das zu analysieren ist da drin.


    Übersehen: Das ist ja KRC2. Da gab es noch keine KRCDiags. In dem Fall würde ich ein vollständiges Archiv ziehen und am besten auch den Log-Ordner C:/KRC/RoBOTER/LOG mit an KUKA schicken. Besonders wichtig sind für solche Fälle Logfiles die TSM*.* oder so ähnlich heißen.


    Fubini

    Code
    $BASE = "Was für ein Frame auch immer du verwenden willst". 


    Also z.B.


    Code
    $BASE = {X 0.0, Y 0.0, Z 0.0, A 0.0, B 0.0, C 0.0} 


    setzt das Base auf die Welt (oder $NULLFRAME wenn du so willst). Schau dir einfach mal den Code im bas.src an. Da steht genau drin was bei dem Aufruf BAS(whatever) passiert.


    Funktioniert solange es sich um ein statisches Base handelt, dass also fest im Raum stehen bleibt.


    Sobald du auf einem bewegten Base unterwegs bist (z.B. auf einem Base, dass sich mit einem Dreh-Kipptisch mitbewegen soll) musst du EK(...) verwenden. Bei Roboteam wäre es LK(...) und bei Conveyor EB(...).



    Fubini

    Du hast da ein Überschleifen von PTP auf PTP. Da gibt es keine Garantien wo der Roboter kartesisch lang fährt. Das eigentliche Überschleifen findet beim PTP im Achskoordinatenraum statt. Du überführst Startachswinkel in Zielachswinkel. Wenn du kartesische Bahnverfolgung brauchst musst du LINs oder CIRCs verwenden. Nachdem das in der Regel langsamer ist als PTPs würde ich sogar SLIN und SCIRC empfehlen.


    Fubini

    In Richtung Anwender sind beide gleich. Unter der Haube hat KUKA nur die HAL (Hardware Abstraction Layer) angepasst, so dass sie die KRC5 Hardware (z.B. anderes Mainboard) unterstützt. Die Roboterprogramme sollten also absolut identisch verwendbar sein.

    Fubini

    Mal ausprobiert


    {E6AXIS: A1 0.0, A2 0.0, ...} oder {E3AXIS: A1 0.0, A2 0.0, ...} oder ...


    Ich vermute mal das hat mit den Defaulttypen zu tun, die die Variablen haben, so dass direkte Zuweisung nicht geht, weil rechts vom = ein anderer Datentyp als links steht. Gibt ja E6AXIS, E3AXIS und AXIS. Ich hab jetzt die Anleitung nicht zur Hand aber da gibt es einen Default der angenommen wird, wenn keine eindeutige Zuordnung möglich ist. Man kann aber den Typ erzwingen durch Voranstellen des Typs wie oben beschrieben.


    Fubini

    Die stehen auch in der $robcor.dat. Irgendwo in den $DYN_DAT[]. Wo genau wird von KUKA nicht veröffentlicht. Was du tun kannst ist $ACC_AXIS runterziehen. Das beschränkt beim Fahren mit Dynamikmodell (den alten PTPs und den Splinebewegungen) die Momente. Für sonstige Bewegungen bekommst du das implizit über Reduzierung von $ACC ebenfalls. Es gibt auch noch das $RED_ACC_DYN (in der R1/$machine.dat glaub ich) das im Prinizip als pauschaler Faktor auf $ACC_AXIS wirkt. Wert von 100 bedeutet 100% allso volle Momente.


    Fubini

    Sorry aber ich bin jetzt neu im Roboterprogrammieren, was meinst du mit Expertenprogramm?

    Du musst es mir so erklären als hätte ich noch nie was mit einem Roboter zu tun

    Das macht aber Support hier wahnsinnig schwierig und nicht zielführend. Du solltest zumindest die Grundlagenschulungen von KUKA besuchen. Vorher kann man glaube ich hier nicht wirklich helfen.


    Bitte nicht falsch verstehen aber Usern über Forumsanfragen die Basics beizubringen funktioniert nicht. Stell dir vor du müsstest jemand der noch nie ein Auto von innen gesehen hat über Forumsbeiträge alles beibringen, dass er die praktische Führerscheinprüfung besteht, Dafür gibt es Schulungen.


    Was hast du denn überhaupt von deiner Seite schon unternommen das du da tiefer reinkommst? Hast du wenigstens die Anleitungen gelesen. Insbesondere das Programmierhandbuch und wenn es um Expertenprogramme, d.h. Programmierung ohne Inlineformulare, gilt das auch das für das Handbuch für Systemintegratoren?

    Was hast du überhaupt für Vorkenntnisse? Bist du Programmierer? Sprichst du wenigstens andere Programmiersprachen als KRL? Das hätte Auswirkung darauf wie man es dir am besten erklären kann.

    Fubini

    Nein. Ist mathematisch nicht möglich. Man braucht zur eindeutigen Definition der Ebene in der der Kreis liegt 3 Punkte. Das kann auch KUKA nicht austricksen.


    Dann mach doch ein Expertenprogramm und berechne dir den Hilfspunkt. Dann musst du ihn nicht teachen.


    Fubini