welchen Kuka Roboter zum 3D-drucken und 3D-Roboterfräsen

Hallo!

Zitat

Ist der KR6 Roboterarm für meine Zwecke gut geeignet? Oder ist der KR16 deutlich stabiler und läuft besser, wenn ich ca 6kg vorne dranschraube?

Wenn ich dich richtig verstehe, willst du 6 Kg an den Robi stecken. Da kommt bestimmt noch 'n bischen Kleinkram zu. Da fällt ein KR6 wohl aus. Die Traglast gilt übrigens nur direkt in der Mitte des Flansches. Liegt dein Schwerpunkt woanders ist's vorbei. Da sollte ein bischen Reserve drin sein.

Zitat

Sollte ich in jedem Fall zur Steuerung KRC2 greifen? Die KRC1 ist zwar deutlich billiger,

Sobald bei der KRC1 was defekt ist kann's teuer werden, weil einige Ersatzteile schon sehr spärlich oder nur für viel Geld zu bekommen sind. Das gilt bei Ersatzteile zwar immer, aber die alten KRC1-Dinger...neee, würd ich lassen.

Zitat

Ist ein alter Roboter mit z.B. 20.000 Betriebsstunden mechanisch schon sehr ausgeleiert? Kann man das irgendwie beziffern, z.B. Spiel von 1...2mm oder ähnliches?

Kann man nicht genau sagen. Es gibt Maschinen, die sind noch gut in Schuss. Kommt auf die durchgeführten Wartungen an, oder ob schon mal die Handachse getauscht wurde oder sonstwelche Getriebe.
Mit einem kleinen Testprogramm kann man die Tauglichkeit recht schnell rauskriegen.

Um die numerischen Daten die Du ihm wahrscheinlich geben wirst einigermaßen korrekt an- und abzufahren, wäre die Option "absolutgenau Vermessen" sinnvoll. Somit erhältst Du eine brauchbare Absolutgenauigkeit.

Hallo,

gute Idee, einen Robi zum drucken zu nehmen. ABER: Wir wollten mal mit nem Roboter fräsen, kamen aber sehr schnell an die Grenzen des machbaren, weil die Bahnen aus zu vielen Punkten bestanden. Ist evtl. kein Problem mehr, keine Ahnung, sollte aber auf jeden Fall bedacht und ggf. getestet werden, ob der Robi die Menge an Punkten verträgt.

mfg ck.poorboy

Zitat von ck.poorboy

...weil die Bahnen aus zu vielen Punkten bestanden. ....
mfg ck.poorboy

Meine Erfahrung zur Info:
- Das Problem gibtes auf KRC2 mit Kuka Cam.Rob
- Unter KRC4 in Kombination mit Kuka.CNC gibt es das nicht mehr. Wir haben damals vor dem Umstieg gezielte Tests durchgeführt. Das Ergebnis war das wir soviel Punkte auf eine Bahn legen konnten welche eine Genauigkeit darstellten jenseits von dem was der Roboter je schaffen würde.

Zitat von Engineering-Art

1.) @ IrrerPolterer: Du erwähnst ein kleines Testprogramm, um zu testen, ob der Roboterarm noch gut funktioniert und noch nicht zu viel Spiel hat. Hast Du da ein fertiges Programm oder wie funktioniert es? Ich würde vermuten ich fahre einen Punkt im Raum an, fahre den selben Punkt nun aus verschiedenen Richtungen an und messe, ob es eine Differenz zwischen der ersten und der wiederholten Position gibt?! So in der Art?

2.) Mir ist noch nicht ganz klar, wie ich den Roboter zum 3D-Drucken am besten ansteuere. Ich habe ein 3D-Modell (im stl oder step-Format) und kann das mit den im 3D-Druck üblichen Slicern in einen Gcode verwandeln mit einer großen Anzahl an Punkten (zB. G1 X37.9 Y31.8 Z22.7 E2.172, der E-Wert entspricht der Position des Kunststoff-Extruders). Am Ende muss ich doch ein Programm in der Kuka Programmiersprache KRL haben, richtig?
Mein Ansatz wäre ein kleines Programm zu schreiben, um die Befehle in das richtige Format für die KRL Programmiersprache zu bringen. Idealerweise kann der E-Wert einen Hardware-Ausgang der KRC2-Steuerung ansteuern, von wo aus ich den Schrittmotor des Extruders ansteuern kann, wohl mit einem zwischengeschalteten ArduinoBoard, dass den Schrittmotortreiber enthält.

3. Sind in einer KRC2 Steuerung immer Hardware-Ausgänge vorhanden?
4. Kann ich diese einfach über die Programmiersprache ansteuern?
5. Haltet Ihr das Vorgehen für praktikabel?
6. Ist das mit geringem Aufwand umsetzbar?
7. Habt Ihr bessere Vorschläge?

Beste Grüße,
Ascan

Alles anzeigen

1.: So kann man das machen.
2.: Auch so kann man das wohl machen. Sehe da aber einige Fragezeichen:
? 1: Speichergrenze wegen der zu erwartenden sehr vielen Punkten.
? 2: Arduinoboard mit Schrittmotor. Wie gross ist denn der Extruder, der Schrittmotor, die erwartete 'Bahndicke'? Immer bedenken, dass der Roboter im Vergleich zu einem aktuellen 3D-Drucker deutlich ungenauer ist.
3.: Nein
4.: Wenn welche vorhanden sind: Ja
5.: Radio-Eriwan-mässig: Im Prinzip ja.
6.: Der Begriff 'gering' liegt im Auge des Betrachters.
7.: Nein

gerade das "gerade Linien fahren" ist einer der größten Schwachpunkte so einer Kinematik...
Ich sehe da mit nem heutigen Roboter noch keine echte Zufriedenheit beim 3-d-Druck. Wird alles etwas winsch aussehen.

Zitat von Engineering-Art

Habt Ihr bessere Vorschläge?

Ich würde, ehrlich gesagt, lieber nach einem passenden ABB gucken, eines der alten Modelle mit Backlink (die Strebe hinter Achse 2) und S4C+. Die sind erfahrungsgemäß für diese Aufgaben besser geeignet. Die Mechanik ist treuer, die Steuerung verträgt eine Menge und kann nötigenfalls sogar einfach Dateien nachladen. Die Dokumentation ist auch besser, die Benutzerführung ist eindeutiger. Vielleicht wäre sogar eine IRC5-Steuerung drin, brächte aber keine ganz großen Vorteile.
Das Problem mit der Offline-Programmierung wird zwar ein bisschen schwieriger, ginge aber auch bei einer KRC2 nicht einfach weg.
So'n alter Kuka kann viel und auch vieles gut, aber für diesen Job wird er nicht Dein Freund, meiner Ansicht nach.

Grüße,
Michael

Ja, den Vorschlag vom Programmiersklaven Michael halte ich auch für gut.

A. geht prinzipiell, beim Kuka einfacher als beim ABB, da man bei Kuka Komponenten einfach weglassen kann. Beim ABB braucht man eigentlich immer einen kompletten Frame; wenn die Orientierung konstant bleibt, ist das aber auch recht einfach gescripted. Soll die Orientierung mit rein, wird es schwieriger.
B: 500000 Bahnpunkte ist garstig. Das wird mit beiden Varianten schwer, beim Kuka aber eher SEHR schwer. Beim ABB sehe ich jetzt keine grundsätzlichen Probleme, wie gesagt, löschen und nachladen, solange es auf die SSD passt.
Beim ABB kenne ich ab S4C+ auch eine Option, sich mit der Steuerung mit einem Netzlaufwerk verbinden zu können um von dort nachzuladen. Das wäre aber eine selten verwendete Option, die man notfalls zum Gebrauchtgerät hinzukaufen muss.
Eine Schwierigkeit dürfte sein, dass Punkte zu nahe beieinanderliegen, je nach Auflösung des Programmiersystems. Erfahrungsgemäß kommt der ABB noch ganz gut klar bei Punktabständen im Zehntelmillimeterbereich, jedenfalls wenn keine Zirkularbewegungen verwendet werden. Notfalls müsstest Du bei der Umsetzung von G-Code nach Rapid (bzw. KRL) die Punktliste bereinigen.
C: das ist abhängig von der Steuerung. Bei S4C+ und höher geht das meist über FTP, unabhängig von oben angesprochener Option. Beim KUKA ab KRC 2 hast Du alle Optionen eines "normalen" Windows-PC. Allerdings gibt es dort eine recht hohe Schwelle zwischen der Windows-Umgebung und der Roboter-Steuerung, die kaum bis gar nicht automatisiert zu überwinden ist.
D: da kann man einige Phantasien verwirklichen.... analoge Ausgänge sind hier wohl das Stichwort. Beide Steuerungen bieten dafür Befehle an, teilweise als Optionspaket. Prinzipiell ist das ja eine ähnliche Anwendung wie eine Klebedüse, und die gibt es bei Robotern schon ewig. Geht m. E. aber auch ohne.
E: bei der Konfiguration des Systems und des Workflows. Außerdem musst Du Dir darüber im Klaren sein, dass bei einem 6-Achsigen Roboter jede Bewegungsumkehr bedeutet, dass 6 Getriebespiele zusammenwirken, 6 Losbrechmomente usw.... es wird nicht immer genau das herauskommen, was Du Dir erhoffst, und an diesen Stellen gilt es, zu tricksen.

Grüße,
Michael

Hi,
hatte am Freitag einen Kunden der das Programm Grasshoper benutzt, das arbeitet auch mit dem G-Code und kann das in KRL umwandeln soweit er es erzählt. Er nutzt das mit einer KR C4 sucht aber grad ne neue Steuerung KR C1/2. Evtl. hilft das weiter.
MfG Pred0509

[size=2][size=2] Pred0509:
[/size]
[/size]
[size=2][size=2]du spielst auf das Programm hier an:

[/size]
[/size]
[size=2][size=2]KUKA|prc (KLR code directly out of Grasshopper) -> yearly fee 350€
[/size]
[/size]
[size=2][size=2]"for free" geht's auch allerdings nur in die andere Richtung:

[/size]
[/size]
[size=2][size=2]KRL 2 G-Code Converter(KRL into G-code)
[/size]
[/size]

[size=3][size=2][size=2]Ach hätt ich doch mehr Zeit für solche Spielereien [/size][/size]
[/size]

Hi 4x4
Der Kunde hatte das kurz erwähnt, da es mich interessierte habe ich danach Google befragt und das Grasshopper3d gefunden. Ob das das richtige ist, kann ich nicht genau sagen, aber wenn ich den Forumsbeitrag richtig verstehe kann das Programm G-Code in KRL umsetzen.
MfG
Pred0509

Hi Pred0509,
könnte man so verstehehn als ob das direkt geht ... stimmt
Mein Cheff flippt aus wenn ich das "mal eben" an der Testzelle probiere aber reizen würd's mich ja schon.....
Gruß
Tobi

Wobei Grasshopper an sich erst einmal selbst ein Plugin für das 3D Grafik Programm Rhino ist. Das kommt dann preislich auch noch dazu.

Ich antworte auch noch mal, auch wenn ich mich eigentlich nur wegen Grashopper eingemischt habe.

Zitat

Allerdings sehe ich die Umwandlung von G-Code in Robotersprache nicht als das größte Problem.

Sehe ich auch so.

Zitat

Rhino+Grasshopper für >1000€ ist erstmal zu teuer.

Ja, wahrscheinlich. Auch wenn ich mit mit der Kombination Rhino plus (Mitsubishi-) Roboter schon gute Erfahrungen abseits des 3D-Drucks hatte.

Zitat

Also kann ich ihm kartesische xyz-Koordinaten zum abarbeiten vorgeben?

Ja.

Zitat

Und noch eine Frage zu meinem vermutlich größeren Problem, die maximale Anzahl an Bahnpunkten innerhalb des Programms.

Wir haben schon 3D-Druck für Kunden realisiert (nicht mit Kuka). Ob die Anzahl der Punkte dabei relevant ist, hängt davon ab, wie das Programm realisiert ist.

Was hier im Thread besprochen wird, ist die Variante aus dem G-Code ein Roboterprogramm zu generieren und dieses dann auszuführen. Das führt zu zwei Problemen: Einmal sind die Interpreter für die Roboterprogramme, gerade auf den älteren Robotern, nicht für so viele Zeilen ausgelegt. Zweitens sind nicht alle Robotersprachen gut darin, Bewegungen auszuführen die aus tausenden millimeterkleiner Stücke bestehen. Bei manchen geht dann die Performance in den Keller.

Aber es gibt andere Arten der Roboterprogrammierung, z.B. das die Bewegungsdaten über Netzwerk von außen geliefert werden, z.B. in festen Schritten, die immer 4 Millisekunden dauern. In so einem Fall ist das Roboterprogramm winzig, es ist nur eine Art Schleife die Daten empfängt und abfährt. Die ganze 3D Struktur liegt nur auf dem PC, den Roboter interessiert nur sein aktuelles Ziel. Bei dieser Art der Programmierung ist die Anzahl der Punkte nur durch den Speicher des PCs begrenzt, also praktisch irrelevant. Außerdem kann man die Bahn und die Dosierung sehr fein steuern.

Hallo Ascan,

selbstverständlich kann man kartesische Koordinaten verwenden, welche sich auf ein Bezugskoordinatensystem beziehen.

XYZ ist wohl fast immer XYZ, nur bei der Darstellung der Orientierung gibt es größere Unterschiede. Solange Du den Roboter das machen lässt, was ein klassischer Portal-Drucker auch kann, ist das fast irrelevant; wenn Du allerdings die Freiheit von A,B und C entdeckst, dann könnte es noch mal etwas Rechnerei geben.

Die Anzahl der Punkte ist beim KUKA begrenzt durch den für VxWorks zugeteilten Arbeitsspeicher, den kann man (ich kann jetzt nur von der KRC2 sprechen) nach der ersten Enttäuschung oft sogar noch hochkonfigurieren. Entscheidend ist hier die Programmgröße an sich. Ich bin allerdings nicht mehr auf Stand, was die Kapazitäten angeht, sondern kann nur sagen, dass ich (wir verwenden das FAMOS-Offline-Programmiersystem) oft an die Grenzen gestoßen bin. Kompliziertere Fräs-Anwendungen waren lange Zeit schon aus dem Grunde kaum möglich. Hier gilt aber wahrscheinlich auch: je neuer, desto größer.

Für ABB würde ich sagen: mindestens eine S4C+ (mit "+"). Da hatten ich schon vor mehr als 12(?) Jahren mehrere Programme mit 7000 Punkten hineinbekommen (solange man sie nicht versehentlich als Persistente deklarierte).

Falls Du Dich mit Urmels Ansatz auseinandersetzen möchtest, die Daten "laufend" von einem externen Rechner an den Roboter zu übertragen (was vielleicht sogar das Vernünftigste wäre in Deinem Fall): das kann der ABB gar nicht, soweit ich weiß, der KUKA hingegen ganz gut. Da bin ich aber raus, damit habe ich keine Erfahrung.

Grüße,
Michael