Alles schon gesehen....
Glaub ich sofort 
. Es gibt Firmen bei denen die Verwaltung es partout schaffen will die gesamte Firma in den Ruin zu treiben. Wenn wirklich alle so wären würden wir heute noch einen C64 im Büro benutzen und jeder der eine Textverarbeitung braucht muss sie selbst entwickeln.
ch würde so gerne wissen wo sich diese werte befinden für das Abfeuern der Meldung M_15016
Nirgends wo man sie sehen und einstellen kann. Die sind hart in die Binaries der Sicherheitssteuerung einkompiliert.
Fubini
Theoretisch ja. Am Ende des Tages musst du "nur" die richtigen Konfigurationsfiles mit den richtigen Inhalten befüllen. Praktisch nein, als Anfänger schon gleich gar nicht. Dafür ist ja gerade WorkVisual gedacht und da ist es wesentlich einfacher weil viel zu beachtende Komplexität einfacher einzustellen ist. Warum willst du WorkVisual nicht benutzen?
Fubini
Funktioniert es mit Klammern?
IF ((STARTEL==3) OR (STARTEL==0)) THEN
$ANOUT[1]=200*(VAR1/100) ergibt 0 ?!
ist wahrscheinlich Null, da du hier Integerdivision machst. Versuch doch mal:
$ANOUT[1]=200.0 * (VAR1 / 100.0)
Fubini
Für KUKA liegt auf jedem Installationsmedium das Programm kue_weg.src bei. Da ist inbesondere auch eine Implementierung von INV_POS() in KRL enthalten und man kann da abschreiben. Ansonsten ist das keine Raketenwisssenschaft. INV_POS ist nichts anderes als die Invertierung einer 4x4 homogenen Transformationsmatrix und das findet man auch in Google/Wikipedia. Einfach mal mit "homogene Transformationsmatrix" googlen. Grob geht es so: Rotationsanteil invertieren durch transponieren, transponierten Rotationsanteil auf den Positionsanteil anwenden.
Fubini
Wir haben die gleiche Systematik an Stäubli TX200 Robotern mit CS8 versuchsweise getestet. Hier lässt sich sehr gut eine geänderte Last anhand den aktuellen Motorströmen der einzellnen Achsen erkennen.
Kein Kritik: Ja und ein VW Golf ist das gleiche wie ein Ferrari SF90 
.
Ich kann jetzt nicht beurteilen wie der Stäubli das macht bei dem Rauschen und sonstigen Einflüßen oder ob er z.B. zusätzliche Sensorik in der Hardware zur Verfügung hat aber leider ist nicht alles was bei einem funktioniert bei allen anderen Roboterherstellern auch so ohne weiteres möglich.
Fubini
Ich fürchte so feinühlig wie ihr hier erwartet ist so eine grosse Maschine nicht. Da bräuchtest Momentensensoren an den Achsen. Das haben in der Regel nur kollorobative Roboter. Standardindustrieroboter schätzen das nur über die Positionsdaten des Resolvers. Die höheren Ableitungen sind dann oft verrauscht und ungenau. Am meisten Feinfühligkeit wäre m.E. noch über die neue Collision Detection machbar. Da wird intern viel Aufwand getrieben die Kräfte und Momente möglichst gut zu schätzen und das erfordert viel internes Wissen über die Steuerung. Ich würde mir die neue Collision Detection mal anschauen. Nur zur Sicherheit: Es gibt die alte Collision Detection die wie du torque_diff und torque_diff2 verwendet. Die neue soll feinfühliger und auch schneller in der Reaktion sein. Details solltest in der Doku zur V8.6 finden.
Fubini
Leider nein.
Am einfachsten installier die KSS neu drüber. Solange es kein SafeRobot ist kein großes Problem. Vorher würde ich aber Archive erstellen und am besten die komplette Festplatte klonen. So kannst du wieder auf den Ausgangszustand zurück, falls was schief geht. Insofern ist das vor Änderungen immer zu empfehlen.
Die Installationsfiles, dass du die KSS neu installieren kannst liegen normalerweise auf D: rum.
Fubini
Hallo,
mir ist von früher noch bekannt, dass es speziell bei den Agiletten immer wieder Probleme bei der Stillstandsüberwachung gab. Ursache war damals, dass sich bei den kleinen Robotern das Rauschen auf den Positionsdaten im Encoder größer ist. Das Fenster (innerhalb der Sicherheitssteuerung) ist einfach unabhängig vom angeschlossener Roboter immer konstant gleich groß gewählt worden. War damals Blödsinn und ist auch heute noch Blödsinn meiner Meinung nach. Daher wurde das irgendwann geändert und das Fenster hat jetzt eine Abhängigkeit zur "Größe" des Roboters und ist auch über die Oberfläche aufweichbar. Hat man wahrscheinlich damals halt für die V8.2 nicht nachgezogen, weil meiner Erinnerung nach "nur" VW noch die V8.2 benutzt und die haben kein SafeOperation (und ich glaub auch keine Agiletten). Ändern von so Fenstern wie $ST_TOL_VEL[] nützt da auch nix, das sind ja nicht-sichere Maschinendaten und als solche nicht zur Konfiguration einer Sicherheitssteuerung erlaubt. Vielleicht liefert das ja gegenüber KUKA ein Argument, dass du den Lizenzupgrade auf V8.3 umsonst bekommst.
Fubini
Oder am besten gleich einen Splineblock nur mit SPL füllen und die Zielpunkte so brrechnen, dass sie auf der Spirale liegen. Dann gibt es das Einschnüren nicht.
Fubini
Würde mich sehr wundern. Schaust du in die richrige machine.dat? Die unter R1 und nicht in STEU.
Fubini
Nein. Bei CP_VEL_TYPE geht es nur um Sollgeschwindigkeiten der Achsen die begrenzt werden bei Singularitäten. Wir reden hier aber von zu hohen Momenten. Ausserdem ist CP_VEL_TYPE eher eine Regelung die während der Ausführung noch versucht zu Retten. Das Dynamikmodell sorgt schon früher dafür, dass es zur Ausführung nichts mehr zu retten gibt. Damit ist das Verhalten deterministisch und nicht wie bei einer Regelung leicht zufällig.
Fubini
Im Normalfall nicht. Es kommt zwar sehr vereinzelt noch vor das bei einzelnen Bewegungen Sollmomentenüberwachungen zuschlagen. Hier kann man dann aber lokal nur dort die Beschleunigung (was in dem Fall eigentlich das Achsmoment ist) leicht reduzieren. Aber was du natürlich schon beachten solltest immer korrekte Lastdaten zu setzen.
Fubini
Genau! Insofern ist das Dynamikmodell genau die Gleichung, die beschreibt wie der Zusammenhang zwischen Achschleunigung und Momenten ist. Das ist aber keine einfache Gleichung wie s = 1/2 * a t^2 sondern deutlich komplexer. Da spielen Wechselwirkungen einzelner Achsen, aktuelle Last, Reibung, Achsposition, Achsgeschwindigkeit, Achsbeschleunigung, ... mit rein.
Das liegt daran das hinter dem alten LIN und CIRC kein Dynamikmodell steckt. Es wird also gnadenlos mit der Beschleunigung gefahren die du eingibst. Als Folge kommt es dan während der Ausführung zum Zuschlagen von üblicherweise Sollmomentenüberwachungen. Ist das der Fall musst du die Beschleunigung rausnehmen. Im neuen Verfahrbereich (Spline, SLIN, SCIRC) ist das inzwischen anders gelöst. Da ist ein Dynamikmodell in Verwendung und der Roboter reduziert quasi implizit einfach soweit dass es gerade noch fahrbar ist und zur Ausführung keinen Meldungen mehr kommen.
Fubini
Nein. Das ist was anderes $RED_VEL ist ein Faktor auf den Override $OV_PRO. Man sollte normalerweise nicht direkt am Override drehen sondern eher am $RED_VEL. Machen insbesondere Technologiepakete von KUKA oft so.
Fubini
Ich weiss jetzt nicht wie genau die Simulation im KUKA.SIM funktioniert. Insbesondere wie da simuliert die Werte entstehen. Da gibts zu viele Möglichkeiten: mit/ohne Office/OfficeLite/Rcs-modul, Maschinendaten mit/ohne Absolutgenauigkeit, Istwerte auf Basis $pos_act/pos_act_mes vor oder nach Elastizätenkompensation, geschwindigkeitsabhängige Bahn durch Filterung, Achskopplung der Handachsen, ...
Prinizipiell kann es solche Effekte geben liegen aber sicher in einem Bereich unterhalb der Genauigkeit des Roboters.
Fubini
Zeile 43 fährst du laut Video im Base und Zeile 54 im Tool.
Herman war schneller.
Fubini
Was passiert wenn du vor Zeile 30 einen Vorlaufstopp über z.B. Wait for true einfügst? Ich vermute mal die Auswertung erfolgt im Vorlauf.
LIN {X 0,Y 0,Z 40,A 0,B 0,C 0}:ZLochgefunden_1
Ausserdem verschiebst du so um 40 mm im Base. Wenn du bzgl. Tool verschieben willst musst du links und rechts vom Doppelpunkt vertauschen. Wahrscheinlich zeigt bei dir auch z+ aus dem Flansch raus, dann brachst eher -40.
https://www.robot-forum.com/ro…?postID=175501#post175501
Fubini
