Beiträge von kai_n

Für was brauchst Du das denn? Vielleicht gibt es da ne einfachere Möglichkeit...

Definitiv nicht. PTP folgt wie LIN auch einem festen Algorithmus. PTP dreht halt jede der 6 Roboterachsen auf den für den Zielpunkt nötigen Winkel. Das besondere daran ist, das die Geschwindigkeit für jede Achse so gewählt wird, dass sie alle gleichzeitig an ihrem Zielwinkel ankommen. Das ist auch schon der ganze Algorithmus...
Was Du vorhast lässt sich relativ einfach mit LIN Bewegungen machen, weil da der Punkt an dem die Bewegung den Endschalter trifft vor der fahrt von Dir berechnet werden kann. Dann kannst Du einen Hilfspunkt berechnen. Wie das dann geht hängt zu stark von Deinen "verbotenen Bereichen" ab, als das man da was zu sagen kann.

Oder noch einfacher: Gibt es nicht einen Startpunkt, von dem aus du alle Zielpunkte sicher erreichen kannst? Oder zumindest eine beschränkte Anzahl Startpunkte und ein Kriterium, nach dem du einen auswählen kannst? Dann kannst Du immer noch die Wege zwischen den Startpunkten fest teachen.

Wenn der Zielpunkt innerhalb des verbotenen Bereiches liegt, wird der Robbie wohl an der "Mauer", also wenn der Endschalter greift, stehen bleiben.
Was hat Du denn vor?

Mmmm... Dann hast Du aber doch quasi Deine eigene SAK-Fahrt programmiert, oder?
Du kannst auch beim Kuka ein Programm in Zeile 10 starten, nur bist Du dann gezwungen die fahrt mit der Totmannschaltung zu machen (also den weißen Knopf halb durchzudrücken, bis die Fahrt forbei ist), das zwingt den Benutzer halt dabei stehen zu bleiben und zuzusehen, was so passiert, was ja auch nicht die dümmste Strategie ist.

Naja, aus der ganzen Erklärerei konnte ich wenigstens lernen, das es keine Dumme, sondern nur ne nervige Frage ist, die halt einfach zu oft kommt. Sollte vielleicht mal nen Zettel drucken, mit ner lustigen Grafik...

DiDi: Wie geht denn so was???

Ernsthaft??? Sorry, ich selber noch nie diese Aufgabenstellung, daher dachte ich genau das wäre mit "endlos drehen" gemeint. Ist das denn Absicht von Kuka? Ich hätte das so nicht erwartet...
In dem Fall würde ich mir das in was gut teilbares einteilen, also nicht 179 sondern 90°, das ganze in ne Schleife, die die Punkte berechnet und $advance auf mindestens 1. Das Ganze eventuell als Unterprogramm myLIN, oder in einen so benannten ;fold damit es im Code nicht so hässlich auffällt... :angel:

Ah, mit dem Bild verstehe ich auch warum Du die Windows-Oberfläche so viel besser findest. Ist durchaus ein Unterschied!

Ah! Da hielft dieser Thread:
http://www.roboterforum.de/rob…e-6-endlosdrehen/0-3.html
Hermann schreibt da zu Frage "Wie kann ich Achse 6 endlos drehen lassen?"

Zitat

dazu die Variable $Axis_Type[6] auf den Wert 5 setzen.

Evtl. noch einen Kaltstart ausführen.

Wenn die Achse immer nur in einer Richtung dreht,
dann muss man nach 1-2 Jahren evtl. mal neu justieren.

Klappt das?
Sorry, hatte das Problem erst nicht richtig verstanden...

Ich kenne die Oberfläche vom KRC32 leider nicht. Hast Du vielleicht nen Screenshot?

Wenn das Programm abläuft liegt das alles in der Verantwortung des Programmieres. Nur zum Start des Programms muss eben der Punkt, auf den sich das jeweilige Programm bezieht, mit einer SAK-Fahrt angefahren werden. Schliesslich konnte die Fahrt von einer unbekannten Startposition zur Programm-Startposition beim programmieren nicht berücksichtigt werden.
Beim Kuka ist das so gelöst, dass die Fahrt zum ersten Punkt eine SAK-Fahrt ist. Wenn man das Programm bei einem späteren als dem ersten Punkt startet (das geht beim Kuka auch), gilt das Gleiche.
Warum sollte man das abwählbar machen? das wär doch super riskant? Wie ist das anderswo gelöst???

Warum muss die Drehung denn maximal 179° betragen?

Wenn Dein Tool fest an Achse 6 hängt, dann gibt es ja keinen Unterschied zwischen der Achse und der Tool-Orientierung um A, oder?

Wenn Du im Tool-Koordinatensystem fährst (also LIN_REL) und Dein Tool so wählst, das es Deine Achse 6 repräsentiert (Ich glaube das ist dann A=0, B=0 und C=180, bin mir aber nicht sicher) dann solltest Du doch die Umdrerhungen von Achse 6 direkt in den A-Parameter setzen können.
Das sollte genauso auch mit LIN funktionieren, da man ja immer die Orientierung im Ziel angibt.
Das Dumme ist nur, das Du wahrscheinlich bei der SAK-Fahrt beobachten wirst, wie der Roboter die Achse 6 die ganzen Umdrehungen zurück dreht, die er beim Programmablauf gemacht hat.

Wer jetzt?
Egal: Herzlichen Glückwunsch!

Ich find das mit dem Windows im KRC2 immer total überflüssig. Die Kuka-Oberfläche sieht überhaupt nicht aus wie Windows, an der Stelle ist kein Vorteil zu sehen. Windows selber bekommt nur 5% der Rechenleistung, den Rest bekommt VxWorks, deswegen kann man mit dem Windows nicht viel anfangen, nicht mal nen USB-Stick sollte man anklemmen. Man kann ja nicht mal nen Windows-Editor zum bequemen Editieren von Programmen nehmen, da VxWorks dann die Änderungen nicht so ohne weiteres mit bekommt.
Man kann auch nicht mit unter windows laufenden Programmen auf die Variablen vom Kuka zugreifen, das ist alles total getrennt.
Die ganzen Netzwerkfähigkeiten von Windows könnte VxWorks auch alleine bieten.
Windows ist da mehr ein Zweckfreier Marketing-Gag.

Oder sieht da wer nen guten Grund?

Klar ist die SAK-Fahrt nervig. aber echt nötig. Der Grund ist so:
Bei einem normalen Programm kennt der Roboter die nötige Bewegungen immer als Start und Zielpunkt, sowie Bewegungsart (Linear, Kreisförmig etc). Der Roboter kennt seine Umgebung NICHT, nur Bewegungen, die OK sind.
Also muss der erste Punkt, von dem aus die für ein Programm nötigen Bewegungen ausgeführt werden immer der gleiche sein. Wenn der Roboter irgendwo im Raum steht (wegen nem Programmabbruch oder so) dann kann er einfach nicht wissen ob die Fahrt zum Startpunkt sicher ist oder nicht, also ob er da was rammt, abreisst oder was weiss ich. Da ist dann die SAK-Fahrt nötig, die unter Aufsicht und mit Totmannschaltung ausgeführt wird, damit halt nichts beschädigt wird.
Ohne SAK-Fahrt wäre das ganze ein bisschen wie Lotto...

Der Grund, warum das so viele Leute fragen ist, das sie halt denken wie Menschen. Sie sehen die Hindernisse ja und für sie ist es einfach denen auszuweichen. Ein Robbie kann das nicht.

Kannst Du ein bisschen genauer sagen, was Du vor hast? Ich glaube einen Befehl wie Du ihn suchst gibt es nicht, wenn Du aber Deine Aufgabe ein wenig erklärst gibt es vielleicht alternative Vorschläge.

Wenn ein Laser nicht genügend reflektiert wird und so klein ist, das er auch in Astlöcher schaut, dann ist Ultraschall doch die einfachere Wahl. So ein Sensor hat ne messkeule von 70°, kommt also recht flächig auf deinem Stapel an. Innerhalb des Messbereichs misst der Sensor den kürzesten Abstand, da er das erste Echo auswertet. Von Holz dürfte Schall auch wunderbar reflektiert werden.
Die Genauigkeit musst Du noch mal nach schlagen, aber ich meine die liegt bei wenigen Millimetern.

Ich hatte mal das gleiche Problem, habe damals ebenfalls keine andere Möglichkeit gesehen. Ich habe die OV_PRO in der SPS gesetzt, in meinem Fall abhängig von einem analogen Eingangssignal. Hab die deswegen nur verkleinert, nie nen grösseren Wert zugewiesen, als OV_PRO bereits enthielt.
Da das in der SPS permanent neu zugewiesen wird, hat man als user kaum ne chance die Geschwindigkeit sonderlich hoch zu setzen.

Kai

Something else just got into my mind: You can also use the device-net directly to communicate. Then all error-handling is done for you, you just have to worry about that you cant really controle when which parameter is send over the bus.