Du kannst dir mal $iosim_opt anschauen. Ist aber nur für simulierte Steuerung gedacht. Eingänge sind halt Ein- und keine Ausgänge. Insofern ist das direkt nicht vorgesehen. Müsstest du sonst über deine SPS handeln.
Fubini
Du kannst dir mal $iosim_opt anschauen. Ist aber nur für simulierte Steuerung gedacht. Eingänge sind halt Ein- und keine Ausgänge. Insofern ist das direkt nicht vorgesehen. Müsstest du sonst über deine SPS handeln.
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
Über die Suchfunktion des Forums solltest du da Beispiele finden. Am Ende des Tages läuft es auf Interrupts hinaus. Beispiele findest zu z.B. auch im englischen Forum hier
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
Nein direkt gibt es das nicht. Da wirst du um das Array oder einen switch case verteiler das enum in einen string konvertiert leider nicht drum rum kommen.
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
Weil ich früher mal bei KUKA in der R&D gearbeitet habe und dort direkt an der Entwicklung beteiligt war.
Fubini
Ja. Genau das meinte ich.
Brauchst du nicht. Ein notepad++ inklusive KRC HIghlighting findest du in jeder krc Installation. Einfach mal nach der exe suchen.
Also z.B.
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
Ach die haben nur am Override gedreht. Hab ich glatt überlesen. Ich dachte über vel_axis.
Override kann höchstens Auswirkung haben ob er einmal Überschleifen kann oder nicht. Kommt denn irgendeine Überschleifen nicht möglich Meldung? Was sagt das System bei Stopnoaprox?
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