Posts by 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

Quote from Robi10

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

Aber natürlich erst nachdem du die Rampe verifiziert hast. Ist ja schließlich ein Sicherheitsthema. Normalerweise garantiert das glaube ich aber KUKA für seine eigenen Kinematiken. Bei Fremdkinematiken können sie das natürlich nicht. Ich würde daher auf alle Fälle auch noch bei KUKA nachfragen, falls alles was du vor dir hast von KUKA kommt.

Fubini

Wahrscheinlich gar keine Singularität. Sonst hätte das Ändern des Turn nicht geholfen.

Benutzt ihr ILF oder Expertenprogramme? Bei Expertenprogrammen klappt Frames tatt E6POS meistens gut. Bei ILF könnte das Rechtemanagment das Teachen von Punkten verbieten für alle, die nicht die erorderliche Erfahrung/Benutzergruppe haben.

Fubini

Einfach mal hier und im englischen Forum danach suchen. Da findet sich was dazu.

Fubini

Schau dir mal $CP_STATMON an. Dient dazu unerwünschte lange Bewegungen aufgrund von Status und Turn zu verhindern.

Fubini

EXT ist eigentlich für Betrieb ohne User gedacht also nein. Hängt jetzt von deinen Softwareversionen ab, aber wenn du Spline verwendest kannst du sowas über einen move_backward() automatisieren.

Fubini

Die Versionen der Maschinendaten bezeichnen aber nicht die zugehörige Steuerungsgeneration. Wenn du schon sowas machst hättest du besser die alten auch auf der neuen Generation verwendet und vorher alt gegen neu verglichen und evtl angepasst. Warum aber sowas überhaupt zu versuchen eerschliesst sich mir nicht. Lieber erstmal mal bei KUKA um die passenden Maschinendaten für deine Steuerung nachzufragen ist besser.

Fubini

UNd auch immer daran denken: Das ist ein Maschinedatum das normalerweise von KUKA fix für jeden Robotertyp ausgelegt wird. Du musst also auch aufpassen dass das ganze Upgrade sicher ist. Insbesondere auch wenn ein WorkVisual Projekt deployed wird.

Fubini

Wann genau? Bei welchen Bewegungstypen. Bei PTP z.B. $VEL_AXIS[], bei LIN,CIRC dagegen geht es nicht. Maximal bei den Überwachungen könnte man weniger zulassen. Bei Splines dagegen schon. Allerdings evtl. erst nach Freischaltung über $SPL_VEL_RESTR.

Fubini

Bei KUKA hat alles feste Nummernkreise. Meldungen "KSS0001" bis "KSS009999" kommen aus der KRC. Meldungen im Nummernkreis 15xxx aus der Sicherheitssteuerung. Insofern lassen sich auch alle Meldungsnummern im Bereich 13xxx einem bestimmten Modul zuordnen. Leider kann ich da nicht nachschauen für wen, d.h. z.B. für welches TechPaket, die 13000er Nummern reserviert sind. Wenn ihr noch eine andere Meldung aus diesem Nummernkreis findet, die ihr sogar in einer Doku habt, hättet ihr zumindest eine Richtung.

Meistens passiert was ihr beobachtet wenn KUKA eine neue Meldung einführt aber vergessen wird die Meldungsdatenbank zu aktualisieren. Die Meldungsdatenbank bringt nämlich erst die internen Nummern mit in alle Sprachen übersetzten Meldungsdaten zusammen.

Fubini

Quote from Martin Huber

$ORI_TYPE_C auf #joint setzen.

Man kann Hauptlaufvariablen nicht aktiv setzen. Das macht das System intern. Zuweisungen sind immer über den Vorlauf zu machen.

$SINGUL_STRATEGY auf 1 zu setzen wird von KUKA abgeraten. Siehe Link in meinem Post #8 oben. Unter der Haube ist das was anderes als $ORI_TYPE=#JOINT. Insbesondere ist das Geschwindigkeitsabhängig. Beim Austesten in T1 funktioniert alles aber in AUT bei Produktionsgeschwindigkeit plötzlich nicht mehr. Das ist bei ORI_TYPE nicht der Fall. Das funktioniert zuverlässig unabhängig von der Geschwindigkeit und immer gleich.

Quote from Stoffel67

$CP_VEL_TYPE ist schreibgeschützt

Mit File war das $custom.dat gemeint. Im Programm kan man das nicht setzen!

Fubini

Als Experte anmelden und dann im File ändern.

Fubini

Vielleicht hilft das ja

Fubini

Klingt mir eher nach einem Problem mit der Singularität. Da gibt es bessere Methoden wie z.b. $CP_VEL_TYPE oder $ORI_TYPE=#JOINT Einfach mal das nachlesen.

Fubini

$config.dat in R1 Ordner. TOOL_DATA[], BASE_DATA[], ...

Beim erstellen eines Archivs wird das mitgesichert.

Fubini

Quote from SCMI

Wenn ich eine überschliffene Position habe und danach kommt eine nicht erfüllte Wartebedingung oder irgend eine andere Art von Vorlaufstopp, dann bleibt der Roboter relativ undefiniert am Anfangsbereich seiner Überschleifzone stehen.

Dafür nimmt man auch das STOP WHEN PATH Feature des Spline.

Außerdem steht er nicht irgendwo ,sondern auf der geteachten Sollbahn. Warum die geteachte Sollbahn, die im normalen Prozessverlauf abgefahren werden soll verlassen und stattdessen auf einen anderen Punkt zu positionieren der "irgendwo" im Raum liegt die bessere Variante sein soll erschließt sich mir nicht.

Ferner hat der Spline nur sehr wenige Gründe warum überhaupt Überschleifen nicht möglich sein kann. Im wesentlichen nur die nicht überschleiffähige Anweisungsfolge und man hat eine Ecke in sein Programm geteached. Alte LIN/PTP haben da duzende teilweise auch schwer verständliche mögliche Ursachen, die zum Teil technisch auch daran begründet sind, dass der geteachte Zielpunkt als Fallback angefahren werden muss und nicht an einem Punkt vor oder am besten am Überschleifbeginn angehalten werden muss.

Ich teile da Woodys Meinung. Meiner Erfahrung nach schlägt der Spline den alten Verfahrbereich an Performance aber auch an Flexibilität und Funktionalität.

Fubini

Kurze Antwort nein. Wird immer wieder mal von ABB-Programmieren hier aufgebracht und man findet (insbesondere im englischen Forum) auch einiges dazu. einfach mal danach suchen. Es gibt Leute mit kreativen Ideen, die mit ein paar Klimmzügen schon mal versucht haben ähnliches nachzubauen mit KUKA Mitteln.

Fubini

Erreicht der SLIN denn den Zielpunkt oder steht er am Überschleifanfang? Schalet er im MSTEP auch nicht?

Fubini