Beiträge von lxuser

    Hallo Student83,


    ist das Thema noch aktuell?


    Um was genaues zu sagen, fehlt mir deine genaue Aufgabenstellung.


    Zumindest die Konfiguration des SafetyEye ist eigentlich recht einfach, die Schutzräume schnell erstellt und mit digitalen Ausgängen der PSS verknüpft.


    Bei SafeOperation (hier fehlen mir jedoch Detailkenntnisse) würde ich grob folgendermaßen vorgehen.
    * Den engsten Schutzraumbereich erstellen und mit Eingängen des Roboters verknüpfen (z.B. Schutztür, Bedienerschutz), die diesen zum Stillstand bringen.
    * Einen weiteren Schutzbereich um den ersten herum legen und diesen auf weitere sichere digitale Ausgänge der PSS legen und mit Eingängen des Roboters verknüpfen, die die Geschwindigkeit reduzieren.


    Den letzten Punkt kannst du dann auch mit Abstufungen machen. Zu den notwendigen Abständen kannst du dann die Nachlaufzeiten bei den Geschwindigkeitsstufen (voll, reduziert) ermitteln und diese mit den Forderungen der Normen berechnen.


    Gruß Mario


    PS: Bist du von der RWTH Aachen? Zumindest haben die meines Wissens nach seit einiger Zeit auch irgendwo ein SafetyEye und einen KUKA KR16 in ihrer Modellfabrik.

    Hallo,


    schau dir mal an, was auf dem Markt so angeboten wird, selektiere es und du kannst dich daran orientieren.


    Ein gutes Beispiel ist meiner Meinung nach die Trainingszelle von KUKA. Mit dem Aufbau lassen sich erste Grundlagen der Roboterprogrammierung wie Pick an Place, auch inkl. Palettenfunktion, Teile vereinzeln und 3D-Bahnprogrammierungen schon mal gut vermitteln.


    Das ganz kann man schön auf eine austauschbare Platte setzen und hier dann im Wechsel Platten mit anderen Applikationen nutzen. Welche das sein sollen hängt dann natürlich auch von dem Schwerpunkt der Schulung ab. Für Mitarbeiter in der Verpackungsindustrie würde sie anders ausfallen, als für Mitarbeiter in Betrieben, in denen z.B. mit dem Roboter geschweißt wird.


    Sensorik und Aktorik lässt sich auch noch beliebig in die Schulungszelle integrieren, z.B. induktive Sensoren, Visionsysteme, Werkzeugwechselsysteme...


    Gruß Mario


    übrigens das programm hatte mal ein Kollege selber geschrieben, für einen anderen Roboter, hatte aber gleich mal es auch für RM-501 kompatibel gemacht :D Macht es wirklich kinderleicht.


    Hallo Ascot,


    wäre es vielleicht möglich mir dieses Programm zu kommen zu lassen? Wir haben hier auch noch zwei RM-501 im Labor.


    Viele Grüße
    Mario

    Hallo,


    bei kleineren Industrierobotern für die Lehre würde ich Mitsubishis bevorzugen.


    Dokumentation und Support sind sehr gut und die Syntax von Melfa Basic verhältnismässig einfach. Dazu kommt noch die gute Einbindung in didaktische Lernsysteme bzw. Simulationen wie CIROS (Vermarktung durch Festo) bzw. die Vorgänger wie Cosimir, Cosiprog...
    Da Mitsubishis auch oft in der Lehre eingesetzt werden, finden sich auch Opensource-Projekte im Internet.


    Viele Grüße
    Mario


    was verstehen sie unter NOT AUS (Pin 1 / 2)


    Daran hängt der Not-Aus-Kreis des Roboters. Die Schaltelemente wie Not-Aus-Schalter, Türkontakte, Lichtgitter... wirken dabei als Öffner wenn sie betätigt werden.


    D.h. der Kreis muss geschlossen sein, damit der Roboter sich bewegt. Im Idealfall mit nach Norm angschlossen Sicherheitseinrichtungen. Brücken würde aber auch zum Testen der Funktion des Roboters gehen. Wie oben aber schon geschrieben bewegen sich andere Typen von IBM schon beim Teachen über den PC mit voller Geschwindigkeit. Eine saubere Trennung zwischen Automatikbetrieb und Teachbetrieb kennt zumindest der 7535 nicht. Es gibt auch nur einen Not-Auskreis und keinen seperaten für den Bedienerschutz (Türkontakte, Lichtgitter...). Daher ist unser IBM so angeschlossen, dass der Roboter nur mit geschlossener Sicherheitzelle laufen kann.


    Gruß Mario

    Hallo,


    der Download ist eigentlich recht einfach zu finden. Unter Simulationssoftware befindet sich ja auch ein Link zu den Downloads, die bei den Praktia sind.


    Ansonsten solltest du mal eure Probleme brauchbar beschreiben:
    * Fehlermeldungen auch mal zitieren
    * Ausführlich beschreiben, was schon läuft, ist der Roboter z.B. mit dem Bedienfeld von Hand bewegbar?
    * Ein paar Bilder von den Anschlüssen, dem Bedeinfeld... machen
    ...


    Mal aus meiner Erinnerung und ohne Gewähr zu den IBMs:
    Bei unserem 7535 und dem 7545 der FH Osnabrück haben die Kabel verschraubbare Rundstecker, die unterschiedlich codiert sind und nur an der richtigen Buchse der Steuerung passen sollten.
    Wenn sich die Steuerung zwar anschalten lässt, sich auf dem Bedienfeld aber nicht die Antriebe des Roboters z.B. mit "Manip Power" freigeben lassen, ist höchstwahrscheinlich der Notauskreis noch offen. Sichert den IBM ordentlich ab. Zumindest der 7535 bewegt sich beim selbst beim Teachen mit voller Geschwindigkeit!
    Habt ihr die AML Software überhaupt? Wenn ja, läuft die Version hier nur unter DOS und nur auf einem untertaktetem Pentium 1. Irgendwas an der Kommunikation über RS232 ist da zeitkritisch, teilweise bekomme ich selbst mit dieser Konfiguation noch einen Verbindungsfehler beim ersten Versuch, danach funktioniert dann aber alles problemlos.
    Außerdem muss die Steuerung für die Kommunikation mit dem PC an sein, die Antriebe freigeschaltet und als Modus "Online" gewählt sein.


    Ich habe allerdings keine Ahnung, was von dem noch bei eurem 7576 zutrifft. Versucht am besten auch mal Kontakt zu jemanden zu bekommen, der noch einen 7576 oder den ähnlichen 7575 im Einsatz hat. Da findet sich über google z.B. http://www.blume-christian.de/IBM7576.htm oder http://www.wolfram-stanek.de/IBM1.JPG


    EDIT:
    Ich hab mir gerade mal die mir vorliegenden Versionen 3.2 und 4.1 der AML-Software angesehen. In beiden ist euer 7576 noch nicht enthalten.


    Gruß Mario

    Hallo,


    schau mal hier rein: http://hmt.fh-duesseldorf.de/hmt/index.php/IBM_7535
    Da findest du für den IBM7535, der auch mit AML/2 programmiert wird, eine 2D-Simulation mit Editor und kommentierte Beispielprogramme als Download.
    Damit solltest du dich schon etwas in AML/2 einarbeiten können.


    Außerdem gibt es noch ein Skript einer anderen Hochschule, in dem AML/2 und einer der alten IBM-SCARA gut beschrieben wird. Wenn ich den Link finde, ergänze ich den hier noch.


    Edit:
    http://www.hs-weingarten.de/~g…obotik/public_html/script
    Ab rob_2.pdf finden sich Informationen zum IBM und AML/2.


    Viele Grüße
    Mario

    Hallo Laurid,


    schreibt doch als erstes ein einfaches Programm für den Kuka, das nach einem Eingangssignal an einem der DIs (erstmal ein Schalter, später ein DO der Kamera) von der seriellen Schnittstelle die X- und Y-Postion liest, über den Punkt fährt, dann runter und den Greifer schliesst. Hier müsst ihr schon zur Siemens-Dokumentation zur ACR20 greifen, die KUKA-Dokumentation gibt zur Programmierung nicht viel mehr als die Bewegungsprogrammierung her. Als Ergänzung zur ARC20-Dokumentation dann die Unterlagen von KUKA zu CREAD.


    Die Position könnt ihr ja erstmal über ein Terminalprogramm zum Roboter schicken und umgekehrt die Positionsdaten von der Kamera mit dem Terminal empfangen. Eine ausführliche Dokumentation zu Provision findet ihr in der Onlinehilfe und im Programmordner gibt es auch noch PDFs, z.b. mit Anwendungsbeispielen. Dazu kommen dann noch Diplomarbeiten mit der VS710.


    Der nächste Schritt wäre dann der Abgleich der Koordinatensysteme von Roboter und Kamera. Also ein Faktor für die Skalierung von X- und X-Achse und die passenden Nullpunktverschiebungen.


    Passen Koordinatensystem und Protokoll zusammen kann dann der Roboter direkt mit der Kamera (DI bzw. DO und die Serielle) verbunden werden. Evt noch ein PC mit einem RS232-Sniffer dazwischen.


    Viele Grüße
    Mario

    Hallo,


    die Frage ist zwar schon ein halbes Jahr alt, aber im Sommersemester befasse ich mich weniger mit den Industrierobotern und habe sie daher nicht gesehen.


    Die lange Zeit zum Hochfahren ist nicht normal. Unser M6100 im Labor ist innerhalb weniger Minuten hochgefahren.


    Wenn er gar nicht mehr hochfährt, können die Pufferbatterien leer sein, die das Betriebssystem des Roboters in einem leider flüchtigen Speicher halten. Diese Batterien sollten alle drei Jahre erneuert werden. Dieser Vorgang ist gut im Handbuch beschrieben. Vom M6100 habe ich hier auch eine recht vollständige Dokumentation (mir fehlt primär der Gesamtschaltplan) vorliegen mit der ich aushelfen könnte.


    Wenn das Betriebssystem gelöscht ist, kann es mit einem Diskettenlaufwerk mit leider properitärer Schnittstelle wieder eingespielt werden.


    Viele Grüße
    Mario


    PS: Bei Problemen mit dem Museumsstück einfach mal bei mir melden, evt. kann ich helfen oder einen Kontakt vermitteln.

    Hallo,


    ich habe hier ein Werkzeugwechselsytem vom GEISSLER MÜNCHEN. Es fast komplett, vorhanden sind Losteile mit verschieden Werkzeugen/Greifern und die passenden Ablagen.


    Nur "netterweise" hat wohl irgendjemand, noch bevor ich das Labor hier übernommen habe, einen alten defekten Bosch SCARA mitsamt des Festteils entsorgt :wallbash:
    Und es stört mich doch ziemlich ein, wenn auch älteres, Werkzeugwechselsystem mit viel Zubehör hier zu haben, es aber wegen dem einem fehlenden Teil nicht einsetzen zu können.


    Eine Artikelnummer ist auf den Losteilen leider auch zu finden, nur Serienummern, z.B. 005059 und 911038/1-4.


    Mal ein paar Informationen:
    - Durchmesser: 65mm
    - 2 Passstifte als Führungen
    - 6 Druckluftanschlüsse
    - 16poliger Stecker


    Bilder liefere ich noch nach.


    Ich würde mich sehr freuen, das Werkzeugwechselsystem wieder benutzen zu können.
    Es wäre super, wenn sich noch ein Festteil finden würde. Ansonsten ist auch alles an Infos willkommen, alte Kataloge, Zeichnungen... Ein Nachbau sollte sich auf den CNC-Maschinen hier auch machen lassen.


    Viele Grüße
    Mario


    Wenn du die Möglichkeit hast, z.B. über irgendeine preiswerte USB-Platine, Bits auf dem PC einzulesen, wäre es eventuell eine Alternative ein Roboterprogramm zu schreiben, also mehrere Zeilen mit Zeilennummer hintereinander senden, das ein Ausgangsbit löscht, die Bewegung ausführt, kurz wartet und dann das Bit wieder setzt. Starten würdest du es dann über den RN-Befehl. Dann würdest du in einer Schleife das Digitalinterface abfragen und auf das Bit warten


    Da würde ich zur K8055 greifen http://www.velleman.be/ot/de/product/view/?id=351346
    Die ist im Internet durch den Einsatz in diversen Projekten in den gängigen Programmiersprachen gut dokumentiert.


    Ich werde mir wohl auch mal 1-2 Stück besorgen um die Kommunikation über DI und DOs simulieren zu können.


    Viele Grüsse

    Hallo Bert,


    danke für deine Antwort.


    Den Akku sehe ich beim Kuka als nicht so kritisch an. Die Daten sind gesichert und und sollten sich nach meinem Wissensstand mit APS ARCH über den Com-Port wieder aufspielen lassen.
    In der Richtung ist eher unserer Hitachi M6100 mein Sorgenkind. Als ich den letztes Jahr übernommen habe, war er ein paar Jahre im Dornröschenschlaf im Keller -> keine Pufferspannung -> Betriebssystem weg. Und da man das nur über ein spezielles Diskettenlaufwerk aufspielen kann, welches weder wir noch die FH in Osnabrück, haben, war ich auf Dritte angewiesen. Zum Glück haben wir die Software wieder aufgespielt bekommen und das zu einem Preis, der wohl nur gut die Fahrtkosten des sehr netten Helfers und das Material gedeckt hat.


    Das Problem bei den ganzen alten Kisten hier ist eh, dass ihr materieller Wert sehr gering ist und somit die Reparaturkosten schnell einen wirtschaftlichen Totalschaden aus ihnen machen können, besonders bei einer nicht gerade üppig gefüllten Laborkasse. Aber der Wert für den Einsatz hier ist durch die vorhandene Software, Dokumentation, Aufbauten... schon recht hoch.



    Schade, dass es bei der KRC32 keine schon vorhandene Lüftersteuerung zu geben scheint.


    Viele Grüße,
    Mario

    Hallo,


    wir nutzen hier einen KUKA IR 363/6 RC30/51C KRC32 an der Hochschule.


    Ein Mitarbeiter einer anderen Hochschule hat mir erzählt, dass ihre Steuerung durch das Ein- und Ausschalten einen Defekt hatte und sie seitdem die Steuerung das ganze Semester durchlaufen lassen. Die Steuerung wäre nicht für regelmäßiges Ein- und Ausschalten ausgelegt. Allerdings ist es nicht wie bei uns einen alte , sondern eine eine KRC1 oder KRC2.
    Gibt es zu unserer RC30/51C KRC32 diesbezüglich Erfahrungen?


    Zurzeit lasse ich unsere Roboter zumindest an den beiden Tagen in der Woche, in denen Praktika statt finden, durchlaufen. Damit man auch mal kurz weg kann, besitzen mittlerweile alle Roboter einen Schlüsselschalter im Not-Aus-Kreis.


    Dauernd durchlaufen lassen will ich aufgrund der Stromverschwendung und auch des Lärmpegels vermeiden.



    Der zweite Punkt ist dann der Lärmpegel, der von der Steuerung ausgeht. Der Lüfter scheint ungeregelt zu sein und es stört ziemlich, besonders wenn mehrere Roboter gleichzeitig an sind. Dabei ist der Kuka aber mit Abstand der lauteste.
    Hier im Forum habe ich mal was zur Lüftersteuerung gefunden. Allerdings leider nicht für RC30/51C KRC32. Ich geh mal davon aus, dass bei der geringen Leistung des kleinen IR363/6.0, auch eine viel geringer Kühlung ausreichen müsste.
    Ist da auch schon original was vorgesehen wo man z.B. nur eine Brücke setzen oder entfernen muss?


    Viele Grüsse
    Mario

    Hallo,


    ich habe gerade den alten Thread gefunden.


    In der Überschrift ist die Rede vom RV-M1, aber auf der Homepage von SL-Automatisierungstechnik finde ich nur den RV-M2. Dann wäre es kein Wunder, dass es aufgrund der anderen Geometrie der Roboters zu Problemen kommt. Oder ist es wirklich eine Version für den RV-M1?


    Viele Grüsse
    Mario

    Da kannst'e auch mehrere Diplom- und Studienarbeiten draus machen :)
    (War selbst 5 Jahre WMA beim Fraunhofer Institut)
    Allein das Thema mehrdeutige inverse Kinematik gibt ja einiges her.


    Mit der Robotik habe ich ehrlich gesagt selbst erst vor drei Monaten begonnen. Nachdem im meinem Fachbereich Maschinenbau der Professor für Handhabung sehr jung verstorben ist, hat der Prof., für den ich ansonsten arbeite, zusammen mit einem Prof. aus dem Fachbereich Elektrotechnik die Handhabung übernommen. Aus der früheren Zusammenarbeit dieser beiden Prof. stammen dann auch die Movemaster, der IBM und der Hitachi. Alle eigentlich schon abgeschrieben, eingemottet und mit netten Hürden bei der Wiederinbetriebnahme. Und auch der Kuka war seit dem relativ plötzlichen Tod des vorherigen Profs. außer Betrieb.


    Daher war ich in den letzten drei Monaten damit beschäftigt, als Bestandsaufnahme, alle Roboter wieder in Betrieb zu nehmen und auf ihre Eignung für Praktika zu überprüfen und die Praktika dann auch direkt durchzuführen.


    Für jedes Praktikum habe ich ein Konzept bis hin zu den Details, das jeweils Unterschiedliche Lernziele berücksichtigt und bei der Vermittlung dieser sowohl die Stärken als auch die Unzulänglichkeiten der veralteten Kisten nutzt.


    Zusätzlich habe ich so genug Arbeitsplätze, um die Studenten in maximal Dreiergruppen aufteilen zu können und somit auch den Einzelnen richtig praktisch mit den Robotern arbeiten zu lassen. Da kommt meiner Meinung nach viel mehr bei rum als bei Demonstrations-"Praktika" an den neuen Modellen, bei denen es leider fast unmöglich ist, die Studenten wegen der Gruppenstärken und dem materiellen Risiko selbstständig arbeiten zu lassen. Zumindest im Pflichtpraktikum, z.B. bei einem ergänzenden Wahlpflichtfach sieht die Sache dann natürlich schon wieder anders aus.


    Jetzt steht bei mir daher erstmal die Fertigstellung der verschieden Praktika an. Von Ausarbeitung der Unterlagen bis Gestaltung der Arbeitsplätze, die von den Sicherheitskonzept dann bei Splittung in kleinere Gruppen, die man dann nicht permanent betreuen kann, wirklich lückenlos sein müssen.
    Das laufende Praktikum war halt doch etwas improvisiert und alles aufgrund fehlender Vorlaufzeit just in time und hat mir nicht wirklich gefallen.


    Parallel dazu sammel ich jetzt mal Infos und Konzepte für eine Wiederbelebung der Forschung, um diese dann direkt in Gesamtkonzept des Labors einfließen zu lassen. Ich muss aber in einigen Bereichen auch erstmal mein eigenes Hintergrundwissen stärken. Aber auch, ob überhaupt Mittel vorhanden sind, mich zumindest mittelfristig zu beschäftigen, steht zur Zeit noch im Raum.


    Das nur mal zu meinem derzeitigen Background.




    Trotzdem zur Orientierung:
    Der Listenpreis des FU liegt AFAIK bei 1000€.
    Das ganze für sechs Achsen + IndustriePC + Peripherer IO + NOTAUS Kette und Schaltschrank
    wird sicher auf 10T€ kommen.



    Schon mal danke für die Informationen.


    Das wird sich allerdings schwer durchsetzen lassen. In der Größenordnung bewegen sich die Angebote zweier Roboterhersteller für 6-Achser. Das sind zwar relativ kleine Modelle im Vergleich zum Hitachi aber die Preise sind schon extrem gut und enthalten einen extremen Hochschulrabatt. Aber der ist mit etwas Glück ja auch bei den Komponenten verhandelbar ;)




    Für kleine Roboter habe ich aber eher sowas im Auge:
    http://www.sdrive.com/german/
    Das dürfte die Lösung deutlich kostengünstiger machen.



    Für erste Tests würde sich auch der IBM 7535 anbieten. Als SCARA mit pneumatischer Z-Achse und geringen Antriebsleistungen würde hier auch erstmal eine kleine 3-Fach-Servo-Endstufe reichen. Die könnte man dann später gegebenenfalls auch für die drei schwächsten Achsen am Hitachi weiterverwenden.



    Viele Grüsse
    Mario