Kommunikationarten und -protokolle der verschiedenen Hersteller

KUKA:
bis KRC2 mit serieller Schnittstelle oder RSI/XML sowie mit jedem handelsüblichen Industriebussystem

Fanuc:
RS232, RS484 und TCP-IP sowie jedes lieferbare Industriebussystem

Mitsubishi:
eingebaut: RS232, 100 MBit-Ethernet (Text über TCP/IP), USB 2.0 (benötigt Treiber)
optional (je nach Modell): mehr serielle Schnittstellen und Ethernet, diverse Bussysteme

Stäubli:
eingebaut: 2x RS232, 2x 100 MBit-Ethernet (Text und Binärdaten über TCP/IP)
optional: diverse Bussysteme

Zitat von brik

Sollte irgendwas unklar sein, habt bitte Nachsicht und fragt nach. Ich kann nicht wirklich auf viel Erfahrung in dem Bereich zurück greifen!

Einen ganz wichtigen Punkt sollte man noch beachten, wenn man Koordinaten zu Robotern verschiedener Hersteller übertragen will:

Die mathematische Darstellung der Koordinaten unterscheidet sich von Hersteller zu Hersteller. Die XYZ-Werte kriegt man noch einheitlich hin, aber Drehwinkel werden unterschiedlich dargestellt.

Grüße

Urmel

wie...

da schreibt man sich ggf eine routine für.

kommt auf den roboter und das gewählte protokoll drauf an

Zitat von WolfHenk

kommt auf den roboter und das gewählte protokoll drauf an

Genau.

Man muss zwei grundsätzliche Arten der Kommunikation auseinanderhalten:

1.) Man schreibt ein Roboterprogramm, das irgendwelche Koordinaten z.B. über TCP/IP empfängt und die dann mit dem Roboterarm anfährt. So was kriegt man mit vielen Robotertypen hin, die Programme (und die Werkzeuge sie zu schreiben) sehen bei den einzelnen Herstellern möglicherweise total anders aus, aber die Daten vom PC können dann (bis auf das erwähnte Koordinatenproblem) sehr ähnlich aussehen.

2.) Wenn man aber mit einer PC-Software ganze Roboterprogramme oder Dateien mit z.B. Positionsdaten auf Robotersteuerungen verschiedener Hersteller herunterladen will, dann ist das viel aufwendiger. Die Programmiersprachen sehen nicht nur unterschiedlich aus, auch die Dateiformate in denen sie auf den Steuerungen liegen sind unterschiedlich (Text, XML, spezielle Dateiformate ...). Auch der Weg wie sie dahin kommen ist sehr unterschiedlich (freigegebenes Windows Verzeichnis, FTP, herstellerspezifischen Datenprotokoll, usw.)

Zitat von brik

So wie oben von mir beschrieben, über ein allgemeines Terminalprogramm oder gibt es von den Herstellern so eine Art Treiber, mit denen man das komfortabler gestalten kann oder eventuell sogar automatisieren kann?

Wie schon gesagt, es ist sehr unterschiedlich, was überhaupt geht, wie es geht und ob es was kostet.

Schon aus diesem Grunde ist eine PC-Software, die angeblich Roboter vieler Hersteller unterstützt, eine schwierige Sache. Entweder kriegt man da den kleinsten gemeinsamen Nenner, der alle Spezialfunktionen ignoriert, oder in Wirklichkeit kann die Software nur mit ein paar Modellen alles und mit den anderen nur ein bischen.

ganz allgemein: Es gibt kein "so wirds gemacht"

jeder kocht hier sein eigenes Süppchen

Wie schon geschrieben, der Datenaustausch über RS-232 oder TCP/IP ist in fast allen Roboterprogrammiersprachen serienmässig enthalten (bei Kuka offenbar nur RS-232), ein Datenaustausch mit einem selbstgeschriebenen Roboterprogramm ist also kein Problem.

Will man dagegen Programme oder Dateien auf den Roboter übertragen, oder irgendwelche Steuerfunktionen ausführen, ohne die selbst programmiert zu haben, wird es komplizierter.

Allgemein gilt, dass die kleineren Roboter (Denso, Mitsubishi, Stäubli) für PC-Programmierer leichter ansprechbar sind. Das hat nichts mit der Größe zu tun, sondern damit, dass diese oft auch in der Laborautomatisierung eingesetzt werden, da findet man schon länger als in der Industrie PCs, die den ganzen Ablauf steuern.

Meist ist es aber dort so, dass es keine fertigen "Treiber" gibt, sondern nur Datenformat- oder Protokollbeschreibungen und man die Anbindung in der Programmiersprache seiner Wahl schreiben kann. Zu den Details sei auf die diversen Unterforen verwiesen.

Bei den größeren Robotern ist es öfters so, dass die Protokolle teilweise nicht öffentlich sind und man ein Development Kit für den PC kaufen muss (z.B. Motoman, Fanuc). Kostet teilweise pro Entwickler und pro Roboter. Andere, z.B. Kuka haben diverse Zusatzoptionen zur Kommunikation (DirLoader, KRL-XML, RSI-XML, ...), die man pro Roboter kaufen muss. Meist ist es aber mindestens so, dass man über Verzeichnissfreigabe oder FTP Dateien auf den Roboter bekommen kann und dort händisch startet.

Zitat von brik

Wie muss ich mir das vorstellen? Was gibt es da für Möglichkeiten, außer in Winkeln von 0° - 360°?

Hallo Brik

Schau dir mal den ABB an da hast du X Y Z Q1 Q2 Q3 Q4 wobei Q1-4 die Quaternionen angeben

http://de.wikipedia.org/wiki/Quaternion

und du glaubst wohl nicht das diese zwei möglichkeiten alle arten sind eine Koordinate im Raum mit Rotation zu beschreiben.

net persönlich nehmen du hast keine Ahnung

Gruß Loipe

Zitat von brik

Wie muss ich mir das vorstellen? Was gibt es da für Möglichkeiten, außer in Winkeln von 0° - 360°?

Du denkst zu zweidimensional.

Die Hand eines Roboters kann in alle Raumrichtungen zeigen, man braucht also mehr als einen Winkel. Und dann ist das nicht mehr eindeutig. Das Problem besteht übrigens auch in der Computergrafik, ist also kein reines Robotikproblem.

Ganz allgemein gibt es mathematisch unterschiedliche Methoden mit denen man die Rotationen darstellen kann:

ABB verwendet Quaternionen:
http://de.wikipedia.org/wiki/Quaternion

praktisch alle anderen Roboterhersteller homogene Koordinaten
http://de.wikipedia.org/wiki/Homogene_Koordinaten

Dabei werden in den Positionen nicht die kompletten Matrizen gespeichert, sondern nur die drei Translationen und die drei Drehwinkel. Bei den Drehwinkeln gibt es zwölf verschiedene Möglichkeiten:
http://de.wikipedia.org/wiki/Eulerwinkel

So haben sowohl eine Kuka- als auch eine Mitsubishi-Position die Form X,Y,Z,A,B,C. Aber bei dem einen ist A die Rotation um Z, bei dem anderen die um X. Dann unterscheiden sich die Reihenfolge der Drehungen, manche drehen zuerst um X, dann Y und dann Z, andere genau umgekehrt. Wie man leicht ausprobieren kann, müssen die Winkelwerte dann jeweils ganz anders sein, damit man nach den drei Drehungen am selben Ort rauskommt. (Mathematisch: Die Matrizenmultiplikation ist nicht kommutativ, A*B ist ungleich B*A.)

Eine dritte Methode ist die Achse- Winkel-Darstellung, die kommt dem nahe was du meinst, wird aber nur selten verwendet, da sie umständlicher ist.

Zitat von brik

...Ich bin für alle Informationen dankbar, aber solche Aussagen bringen mich (und wahrscheinlich auch niemand anderen) weiter.

Wie aus meinen Ausführungen hervorgehen sollte, kenne ich mich mit der Materie nicht aus und versuche mir auf diesem Weg einen Einblick / Überblick zu verschaffen....

Dann mußt Du Deine Fragen soweit konkretisieren, daß Du ein oder zwei Lösungsmöglichkeiten hast.

Konkrete Beispiele?
Am End gar ein Stück fertigen Programmcode?
Das klingt fast wie "Ich will mit anderer Leute Arbeit Geld machen!"
übel...

Deine momentane Fragestellung ist wie eine Bettdecke. Sie reicht vom Hals bis zu den Füßen.
Ein Arzt würde jetzt auch zuerst fragen wo es denn genau wehtut, denn er wird kaum die Knie behandeln, wenn Du Bauchweh hast.

Es gibt mindestens sieben gangbare Kommunikationswege mit jeweils einigen Protokollen.
Somit einige zig Möglichkeiten das zu tun.

Du hast nun RS232 am KRC2 genannt. Damit bleiben vier Protokolle und ein paar Mögliche Wege über, es ist also nun eingrenzbar.
Jede Position besteht aus sechs oder mehr Realzahlen aber dazu vielleicht später...
Erst mal das Protokoll: Der Server stellt die Zahlen zur Verfügung, der Roboter holt sie ab.
WIE holt der die ab? Welches Kommunikationsprotokoll soll laufen? Welche Geschwindigkeit? (Entfernung bei RS232 beachten) Fehlererkennung? Kommunikationssicherheit?

Also immernoch tausend Fragen....

Schlußendlich bleibt der Blick ins Handbuch bei cread und cwrite

Das wars also.

Im übrigen solltest Du mal über Sprichworte nachdenken...

Also, wenn ich im anderen Thread lese, dass BRIK verschiedene Hersteller von Palettierprogrammen und die Anbindung an verschieden Robotersysteme vergleicht, und hier Kommunikationslösungen unabhängig vom Roboter-Hersteller sucht, sieht dies für mich zunächst so aus, als gehe es um die Entwicklung einer Palettieranlage zur Integration verschiedener Hersteller.
Also ich helfe gern, aber Entwicklungsarbeit leiste ich nicht. Und danach sieht es hier aus. Sorry.