Beiträge von Lenneper

Zitat von fubini

Hallo,

der KUKA-Spline ist polynomial (5.Grades).

Gruß
Fubini

Hallo Fubini,

entschuldige bitte, wenn ich so einen alten Thread auspacke, aber woher hast du die Information, dass der KUKA-Spline ein Polynom 5. Grades ist?

Vielen Dank für deine Hilfe und beste Grüße!

Sorry, dann habe ich meinen "Pseudo"-Code wohl etwas verfälscht vereinfacht. Die Funktion heißt eigentlich nicht Trigger, sondern anders. In dieser Funktion wird einfach nur ein Output gepulst und die aktuelle Position abgespeichert. Nichts Weltbewegendes also, sodass ich den Fehler auch nicht an dieser Stelle vermuten würde?

Habt ihr denn noch andere Ideen parat als eine Vielzahl gestaffelter Jobs zu implementieren?

Hallo zusammen,

ich arbeite mit einem Roboterprogramm, in welchem ein SplineBlock variabler Länge gefahren werden soll. Dies geschieht über ein großes Array, in welchem alle Positionen gespeichert werden:

SPLINE WITH <Options>
    SPL SplinePositions[1]
    SPL SplinePositions[2]
    ...
    SPL SplinePositions[100]
ENDPSLINE

Selbst wenn ich nur die ersten 20 Stellen der SplinePositions befülle, dann wird die letzte Position in alle nachfolgenden Positionen des Arrays kopiert. Die Steuerung springt dann recht schnell über die leeren/kopierten Positionen hinweg. Dies funktioniert im Grunde ganz gut.

Nun möchte ich jedoch an jeder der SplinePositions einen Trigger ausführen. Dies habe ich mit viel Copy&Paste erstmal so gelöst:

SPLINE WITH <Options>
    SPL SplinePositions[1]
    TRIGGER WHEN PATH=0 ONSTART DELAY=0 DO Trigger() PRIO=-1
    SPL SplinePositions[2]
    TRIGGER WHEN PATH=0 ONSTART DELAY=0 DO Trigger() PRIO=-1
    ...
    SPL SplinePositions[99]
    TRIGGER WHEN PATH=0 ONSTART DELAY=0 DO Trigger() PRIO=-1
    SPL SplinePositions[100]
ENDPSLINE

Jetzt kommt der Knackpunkt: Wenn ich diesen SplineBlock mit nur wenigen X Positionen starten möchte, dann bekomme ich einen Laufzeitfehler, dass die maximale Anzahl an Interrupts überschritten wird. Dies kommt daher, dass beim "Überspringen" der leeren SplinePositions die Trigger erstellt werden. Sobald mehr als 32 Interrupts angelegt wurden, steigt das Programm aus. Wenn ich dasselbe Programm jedoch mit 80-100 Positionen befülle, dann läuft es wunderbar...

Wie kann man ein solches Vorgehen am besten implementieren? Ich habe die SplineBlocks auch schon in einer FOR-Schleife angelegt, doch leider werden die einzelnen SplineBlocks dann nicht überschliffen, sodass der Roboter immer wieder stehen bleibt.

Kann ich irgendwie sicherstellen, dass die Trigger auch bei leeren/kopierten SplinePositions hintereinander ausgeführt werden, quasi als ob die Positionen vom User angegeben worden wären? Oder kann ich die Trigger über eine Variable deaktivieren sobald ich innerhalb der Trigger-Funktion die gewünschte Anzahl an Triggern erreicht habe? Ich kenne die Anzahl ja vor dem Start des Jobs und könnte somit mitzählen?

Schön wäre es, wenn man beim TRIGGER WHEN Befehl noch eine Bedingung über IF angeben könnte, aber das gibt es wohl nicht? Habt ihr noch bessere Ideen, wie man ein solches Vorhaben realisieren könnte?

Vielen Dank für jede Hilfe und ein schönes Wochenende!

EDIT: Mir fällt sonst als letzte Alternative nur ein, dass ich verschiedene Funktionen desselben Bewegungsablaufes mit gestaffelter Anzahl an Positionen implementiere, zum Beispiel so:

• Bahn_30: Implementiert SplineBlock mit 30 Positionen und wird gewählt, wenn der User weniger als 30 Positionen angibt
• Bahn_60: Implementiert SplineBlock mit 60 Positionen und wird gewählt, wenn der User mehr als 30, aber weniger als 60 Positionen angibt
• Bahn_90: Implementiert SplineBlock mit 90 Positionen und wird gewählt, wenn der User mehr als 60, aber weniger als 90 Positionen angibt
• [...]

Wäre aber meiner Meinung nach eine ziemlich hässliche Art das Problem zu lösen?

Hallo zusammen,

ich habe ein Roboterprogramm, welches aus mehreren Tasks besteht. Ich kann diese beispielsweise händisch über die Titelleiste per Knopfdruck auf den "S"-Button zu- oder abwählen.

Ist es auch möglich die Submodule aus dem Roboterprogramm heraus zu kontrollieren, also zu starten oder zu beenden?

Besten Dank für euren Input

EDIT: Wäre es zum Beispiel möglich den EX1 Submit-Interpreter-Task (Module1.sub) aus dem Roboterprogramm neuzustarten über?

CWRITE($CMD, STAT, MODE, "CANCEL 3")
CWRITE($CMD, STAT, MODE, "RUN/R1/Program/Modules/Module1() > 3")

Hallo zusammen,

entschuldigt bitte die recht unkonventionelle Frage, aber ich bin ein absoluter Neuling auf dem Gebiet der Roboterprogrammierung. Trotzdem muss ich aktuell ein relativ kompliziertes Roboterprogramm debuggen, welches aus mehreren Tasks besteht und auch interrupt-basiert arbeitet. Leider läuft das Roboterprogramm absolut sporadisch in einen Deadlock. Bisher habe ich in diesem Fall das Programm zurückgesetzt und neu gestartet, doch führt dies leider zu kleinen Abweichungen in den Ergebnissen eines sehr sensibles Messaufbaus. Daher möchte ich die Zeit zwischen Weihnachten und Neujahr gerne nutzen mich intensiver mit dieser Problematik auseinanderzusetzen.

Um den Fehler weiter einzugrenzen, würde ich gerne mit irgendwelchen Debugausgaben anfangen - zum Beispiel eine Ausgabe in der Info-Box auf dem SmartPad oder etwas in der Art. Bietet KUKA (in einer KRC4) hierfür eine Möglichkeit an? Fallen euch vielleicht noch andere Wege ein, wie man gewisse Programmabschnitte nachvollziehen kann?

Natürlich kann man das Roboterprogramm auch mit WorkVisual debuggen, doch empfand ich das bisher als relativ anstrengend. Insbesondere, da der Fehler nur sporadisch auftritt und vermutlich mit den Interrupts zusammenhängt. Daher meine Frage nach den Debugausgaben, in der Hoffnung, dass sich damit komfortabler arbeiten lässt.

Vielen Dank für euren Input und fröhliche Weihnachtsfeiertage an Alle!

Hallo Sven,

vielen Dank für den Screenshot. Aus welchem Dokument ist dieser?

Vielen Dank und schöne Grüße!

Hallo zusammen,

ich habe eine kurze Frage zu den Einheiten der Lastdaten, welche ja in der Form {M 6.50000,CM {X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0},J {X 0.0,Y 0.0,Z 0.0}} anzugeben sind.

M: Masse, kg, klar

CMx, CMy, CMz: Position des Massenschwerpunkts, wird dieser analog zu KUKA.Load in Millimetern angegeben?

CMa, CMb, CMc: Orientierung der Haupt-Trägheitsachsen durch den Masserschwerpunkt in ABC/ZY'X''-Notation, wird vermutlich in Grad angegeben?

Jx, Jy, Jz: Trägheitsmomente, welche entlang der Haupt-Trägheitsachsen wirken, wird vermutlich analog zu KUKA.Load in kg*m^2 angegeben?

Die zweite Frage bezieht sich auf die Orientierung des Koordinatensystems zur Berechnung der Lastdaten: In der KR CYBERTECH Betriebsanleitung finde ich die Traglasten für meinen Roboter ab Seite 21 (KR8 R2010). In Abbildung 4-5 ist das Koordinatensystem eingetragen: Ist dieses für die Orientierung A=0°, B=0°, C=0° angegeben?

Vielen Dank für eure Hilfe

Hallo SJX,

vielen Dank für die Daten aus V5.0.22.

Wenn ich diese in die neue Version (V5.0.24) übertrage, dann bekomme ich eine Freigabe mit dem Hinweis "Taktzeitanalyse empfehlenswert". Ich bin bereits in Rücksprache mit KUKA: Der Servicemitarbeiter klärt dieses Problem mit der Entwicklung ab.

An unserem Roboter ist eine Smart-EZ (NW42) mit der Artikelnummer 0000 278 780 verbaut. Diese ist leer und besteht nur aus dem Schlauchpaket und dem Gehäuse mit Spannfeder, welches auf der Achse 3 montiert ist. Es würde mich doch wundern, wenn der Aufbau 10kg schwer ist. Wählt Kuka hier bewusst sehr konservative Werte um eine Überlastung zu verhindern?

Vielen Dank und schöne Grüße!

Hallo zusammen,

wir stehen kurz davor unsere Greiferkonstruktion am Roboter-TCP zu montieren und dabei hat sich eine Frage bei der Verwendung von KUKA.Load ergeben. Ich freue mich über jede Hilfe, da ich absoluter Neuling auf diesem Gebiet bin. Anbei erstmal die Eckdaten zum System:

Lastdaten (am TCP):

Masse: 8,10kg

Schwerpunkt X: 0,003 mm

Schwerpunkt Y: 1,027 mm

Schwerpunkt Z: 54,13 mm

Trägheitsmoment im Schwerpunkt Ix: 0,0358 kgm^2

Trägheitsmoment im Schwerpunkt Iy: 0,0347 kgm^2

Trägheitsmoment im Schwerpunkt Iz: 0,0170 kgm^2

Verwendeter Roboter: KR8-R2010-2

Wenn ich diese Lastdaten in KUKA.Load eingebe, bekomme ich eine Freigabe. Allerdings verfügt unser Roboter über einen Kabelschlauch zum TCP hin mit (schwarze Box auf der dritten Achse mit federkraftgestützter Spannung des Kabelkanals, ähnlich wie der erste Roboter in diesem Bild). Ich vermute diese Einheit wird als K-Box bezeichnet? Wenn ich diese in KUKA.Load als Zusatzlast für die 3. Achse auswähle (12,6kg Masse), dann erhalte ich eine statische Überlastung des KR8-R2010-2 - selbst wenn 0kg Last am TCP anliegt? Es scheint also, als wäre die K-Box für unseren Roboter nicht geeignet? Komisch erscheint mir bei der K-Box auch der Schwerpunkt bei (Lx 82mm, Ly 160mm, Lz 106mm), obwohl der meiner Meinung nach bei ca. Lz=-1000mm liegen müsste? Die Kiste doch recht weit zu Beginn der 3. Achse montiert? Das Gewicht von 12,6kg für einen leeren Kabelschlauch und eine Feder, montiert auf einer Grundplatte, erscheint mir auch außergewöhnlich hoch?

Wenn ich als Bauform "fix" auswähle (4,3kg Masse, Lx 138mm, Ly 52mm, Lz 112mm), kann ich mit dem obigen Schwerpunkt und Trägheitsmoment bis ca. 7,6kg Last hochgehen, bevor eine Überlastung des Roboters gemeldet wird.

Wenn ich die Zusatzlast für Achse 3 auf Nennwerte setze (10kg Masse, Lx -105mm, Ly -74mm, Lz -995mm), dann kann ich problemlos mehr als 8,10kg Masse am TCP betreiben.

Falls mir jemand helfen könnte, wie die Energieführungskette in KUKA.Load eingegeben werden muss, wäre ich sehr dankbar. Ich kann mir kaum vorstellen, dass das Default-Gewicht von 12,6kg aus KUKA.Load für unser Modul stimmt. Die Option "fix" erscheint mir falsch, da wir ja einen Federzug zur Spannung des Kabelschlauchs haben.

Leider konnte ich im KUKA-Portal keine wirkliche Dokumentation zu den verschiedenen Energieführungsketten finden. Mal schauen ob ich morgen eine Artikelnummer am Modul entdecke...

Ich freue mich wie gesagt über jede Hilfe. Vielen Dank für eure Zeit!