Beiträge von Urmel

    Hallo,


    unseres haben wir vor Jahren schon entsorgt. Tut mir leid.


    Aber das hatte sowieso einen Parallelport Dongle. Da müsste man dann auch noch ein passendes Motherboard finden.


    Bei der Mitsubishi M-Serie gibt es allerdings nicht wirklich viel, wozu man eine PC Software brauchen würde. Der kann wirklich nur die Befehle, die im Handbuch stehen. Ein Protokoll für eine PC-Software gab es erst in späteren Generationen. Dass man da irgendwas mit einer PC-Software konfigurieren kann, ist also Fantasie.


    Da reicht jede Scriptsprache, die mit der seriellen Schnittstelle umgehen kann, oder ein Terminalprogramm, dass die Zeilen als ganzes Senden kann, nicht jedes Zeichen beim Tippen einzeln, das mag der Robbi nicht.


    Grüße Frank

    Ich bin kein großer Fanuc Experte, habe aber gerade praktischerweise ein Fanuc Handbuch vor mir, wo ein Absatz dazu steht, der zumindest Hinweise gibt (B-84184EN/02, Remote Motion Interface).


    Zitat

    Note that a motion instruction with continuous termination type (CNT1-100) will not execute until the next motion line comes in, to make sure the two motions can blend together correctly. Therefore, make sure that the last motion instruction you send to the controller is with FINE termination type.

    Das könnte bedeuten, er läuft immer bis zur nächsten Bewegungsanweisung voran. Außer es handelt sich um eine mit CNT 0 oder FINE.

    Ich bin Softwareentwickler, kein Motorexperte.


    Wenn du entsprechende Motoren hast, dann nimm die.


    In Cobots oder echten Industrierobotern habe ich bisher aber immer nur irgendeine Art von Synchronmotoren mit Encoder gesehen. Natürlich mit Getriebe, z.B. Harmonic Drive.


    Im Wikipedia Artikel zu Schrittmotor steht ja das dazu. Im Prinzip geht das schon irgendwie ineinander über.

    Zitat

    Treibt man den Mikroschrittbetrieb zu einer noch feineren, quasi-analogen Auflösung weiter und kombiniert sie mit einem Weg- oder Winkelmesssystem zur Positionsrückführung, so erhält man einen hochpoligen Synchron-Servomotor und damit den stufenlosen Übergang zu der niederpoligen Drehstrom-Servotechnik. Der Schrittmotor – der in dieser Betriebsart eigentlich keiner mehr ist – profitiert hier weiter von seiner preisgünstigen Bauweise und erlangt Eigenschaften wesentlich aufwendiger gebauter und teurerer Motoren.

    Naja, als Bastler wird man wenig Alternativen haben. Wenn du sehen willst, wie es die Profis bei kleinen Armen machen, schau z.B. bei Faulhaber oder Maxon. Da könnte man ja eventuell immerhin noch beim Arduino als Steuerung bleiben.


    Mit Schrittmotoren wird das nicht so gut skalieren, wenn der Arm länger werden soll oder mehr Traglast haben soll. Man braucht mehr Drehmoment, entsprechende Motoren wären viel schwerer, also braucht man noch mehr Drehmoment. Die Spannung ist begrenzt, also viel Strom und dicke Kabel, noch mehr Gewicht.


    Dann ist da natürlich die Störfestigkeit. Beim Roboter oben sitzt der Teensy auf einen Schraubklemmenmodul. Die 3,3 V Signale werden über verschaubte Kabelverbindungen zu den Schrittmotormodulen geleitet. Das wird im Klassenraum gehen. Wenn da jetzt eine Maschine oder ein Schweißgerät in der Nähe ist, dann wird es zumindest spannend.


    Die richtigen Industrieroboter benutzen meist sowieso Drehstromservos mit vielen hundert Volt. Das ist nichts für den Eigenbau.

    Hier ein Beispiel AR4

    Nett.


    Habe mir gerade mal den Quellcode für den Teensy angesehen. Macht einen sehr ordentlichen Eindruck. Und der größte aller Arduinos (600 MHz) wird auch ausreichen die Kinematik zu berechnen.


    An dem Stapel Schrittmotorsteuerungen bei den Bauteilen sieht man allerdings, was ich meinte. Da kommt man bei diesem Arm mit 1 kg Traglast und 600 mm Reichweite wahrscheinlich schon in Bereiche wo Schrittmotoren selten und teuer werden.


    Ob das für Maschinenbeladung und Schweißen reicht, muss der Fragesteller beurteilen.


    Grüße

    Urmel

    Hallo,

    Ich möchte schliesslich nicht jede Achse selber Programmieren sondern nur mit dem Toolcenterpoint verfahren.

    einige SPS Hersteller bieten wohl sowas an. Ist halt die Frage, ob es zu den Schrittmotoren passt. Die sind ja selber auch wieder ein Problem, man hat da ja Motoren von ein paar hundert Watt bis ein paar Kilowatt. Das wird mit Gleichstrom lustig.


    Ansonsten wüsste ich da nichts fertiges. Eventuell hier schauen

    The Orocos Project – Smarter control in robotics & automation!

    vielleicht auch bei ROS.


    Grüße

    Urmel

    Ich habe das Handbuch schon geschickt. Hier rechts ganz oben auf der Seite sollte ein Symbol mit zwei Sprechblasen sein, da sind die privaten Mitteilungen.


    Der Roboter ist wirklich schon älter. Wenn er von 1999 ist, ist er einer der letzten die gebaut wurden. Das Nachfolgemodell ist 1998 auf den Markt gekommen. Nach den Copyrights im Handbuch ist der E2 1994 auf den Markt gekommen.

    Also unsere Cosirop Sachen sind schon vor Jahren im Müll gelandet.


    Wahrscheinlich beruht das mit dem RCI Explorer auf einem Mißverständnis. Cosirop war ein Produkt der Uni Dortmund, das Mitsubishi Deutschland in Mitteleuropa als Programmiersystem für die Roboter verkauft hat, weil die japanische Software damals nicht auf dem europäischen Markt verkauft werden sollte. Wahrscheinlich ist dieser RCI Explorer eine andere Software für diese Roboter und man fantasiert sich da jetzt was zusammen, dass das zu Cosirop gehören wurde.


    Compiliert wird für diese Robotersteuerung gar nichts in Cosirop, das überträgt auch nur ASCII Text zeilenweise. Melfa Basic ist auch auf den heutigen Robotern eine interpretierte Sprache und wird als Text übertragen. Treiber braucht man auch bei aktuellen Mitsubishi nur bei Verbindung über USB.


    An der seriellen Schnittstelle hängt bei dieser Steuerung wirklich nur die Kommandozeile von Movemaster Command, im Prinzip arbeitet man wie bei einem alten Homecomputer. Mehr geht da nicht.


    Theoretisch sollte ein geeignetes Terminalprogramm möglich sein. Wichtig ist, dass ganze Zeilen gesendet werden, nicht jedes getippte Zeichen einzeln, das führt zu Fehlern. Und der Zeilenumbruch muss stimmen, normalerweise ein einzelnes CR.


    Öffentlich kann ich das Handbuch hier nicht einstellen. Ich könnte mal schauen, ob das als Anhang an persönliche Nachrichten geht. Sind allerdings mehrere Teile, mit insgesamt ca. 60 MB.

    Hallo,


    ich habe damals mit Cosirop an den Dingern gearbeitet, ein RCI Explorer ist mir dabei nie begegnet. Das müsste mit Cosirop alleine gehen.


    Wir haben dann ziemlich schnell eigene Software für die Roboter geschrieben. Bis auf ein paar Spezialitäten beim Lesen von Positionen ist alle Kommunikation im Programmierhandbuch beschrieben. Es sind eigentlich nur die Movemaster Command Befehle, die da direkt gesendet werden.


    Das technische Handbuch scheint es nie als fertiges PDF gegeben zu haben, wir haben hier auch nur einen Scan auf dem Firmenserver.


    Das Nullsetzen dürfte in der Tat das große Problem bei diesen Roboter sein. Daran sind die meisten kaputt gegangen, dass sich einzelne Achsen nicht mehr Nullsetzen liessen. Dann musste der Motor getauscht werden.


    Grüße


    Urmel

    Ne, zu ABB habe ich gerade nichts da.


    Hier ist das bisher beste Beispiel für Fanuc, das ich kenne. https://control.com/technical-…obot-programming-example/


    Stäubli speichert seine Projekte leider als XML. Die Formatierung sieht komisch aus, wenn man versucht das hier hinein zu kopieren.


    Muss mich erst mal wieder um anderes kümmern.

    [Edit]

    Schau mal hier, mit kompletten Val3 Kurs: https://www.oth-aw.de/files/ot…_und_Handhabung_final.pdf


    [Nochmal Edit]

    Beschreibt allerdings die alte CS8 Steuerung. In der aktuellen CS9 kann seine User Interfaces in HTML schreiben, die alte Bildschirmausgabe gibt es so nicht mehr. Die Programmierung der Roboterbewegung ist aber gleich.

    Ja, mit ABB hatte ich auch schon mal zu tun. Hat auf jedem Fall eine deutlich mächtigere Programmiersprache, als Fanuc. Ähnlich mächtig wie Stäubli, aber ganz anders.


    Fanuc sieht sehr konservativ aus. Programmierungsprache aus den 70ern oder 80ern, behutsam weiterentwickelt. Wird bei uns die anderen Hersteller sicher nicht verdrängen. Aber wenn der Roboter nur irgendwo was hinhalten soll, gehe ich davon aus, dass er das gut kann.

    Also Mitsubishi hat eine Art Basic als Programmiersprache. Kann man sich vorstellen, wie einen alten Homecomputer plus Bewegungsbefehle. Allerdings gibt es zusätzlich noch die Möglichkeit von einem externen Rechner aus mit C++ zu arbeiten.


    Programmierhandbuch gibt es zum Download unter de3a.mitsubishielectric.com . Da rechts auf Download gehen und Suchbegriff BFP-A8869 eingeben.


    Stäublisch (also Val3) ist eine eher komplexe Sprache, da muss ich mal ein einfaches Beispiel suchen.


    In diversen Details, z.B. Tasten auf dem Handbediengerät, finde ich gerade viele Parallelen zwischen Fanuc und älteren Mitsubishi. Die Japaner scheinen da alle ähnlich zu ticken.


    Doku ist auf jeden Fall ein Unterschied bei Fanuc. Auf der DVD beim Roboter sind wohl nur Unterlagen zu Wartung und Installation. Programmieranleitungen und Infos zu den gekauften Optionen muss man denen alle einzeln aus der Nase ziehen. Zugangsgenehmigung zur Doku Webseite scheint eine Weile zu dauern.

    Hallo,


    ich muss gestehen, an so einem Thread hätte ich auch Interesse.


    Kann zwar keine Vergleiche zu Kuka ziehen (habe bisher nur mit dem LBR gearbeitet), freunde mich aber gerade mit jahrzehntelanger Mitsubishi und Stäubli Erfahrung mit einem Fanuc an. Der steht aber immerhin schon hier, so kann ich bei Bedarf zumindest einige erste Eindrücke teilen.


    Grüße


    Urmel

    So weit ich das verstehe nutzen solche Lösungen die Gelenkströme vom Roboter selbst um eine Kraft abzuschätzen. Hat das irgend jemand schon mal gehört oder geshehen?

    Wir nutzen bei Mitsubishi und Stäubli nicht die fertigen Kraftsensor Lösungen, sondern die "Echtzeitsteuerungen", wo man die Roboter im Interpolationstakt ansteuern kann. Da hat man teilweise auch den Zugriff auf die Motorströme. Das ist verglichen mit einem Kraft-Momenten-Sensor eine eher grobschlächtige Angelegenheit. Einen Kraftsensor kann man so fein einstellen, dass man dem Roboter durch Antippen mit dem kleinen Finger bewegen kann, mit den Motorströmen kann man eher kontrollieren, ob man irgendwo fest steckt.

    Danke für das Update.


    Deine Beschreibung der Verzögerungsschaltung klingt plausibel. Auch sieht es in der Tat so aus, dass der Mainboard Teil noch ziemlich ok ist.


    Die Temperatursicherung hat aber wohl nicht aus Jux ausgelöst. Wahrscheinlich hat ein Fehler in der Leistungselektronik den Widerstand überhitzt. Da müsste dann noch was anderes kaputt sein, wodurch jetzt kein höherer Einschaltstrom mehr fliesst.

    Hallo,


    das müsste schon mit der Multiplikation gehen, dafür steht ja das *.


    Wenn du eine PSps geschickt bekommst, wäre eine relative Toolbewegung damit z.B. Mov P_Curr * PSps . Ist auch irgendwo im Handbuch bebildert, wo die Multiplikation von Positionen beschrieben ist.


    Grüße


    Urmel

    Ich habe mir mal etwas die Bilder angesehen.


    "Controller.jpg" zeigt, dass die Steuerung um ein PC Motherboard herum aufgebaut ist. Man erkennt da einen Intel "i287 XL" Koprozessor, d.h. da wird wo noch ein 80286 Prozessor daneben sein. Also vermutlich alles Mitte der 1980er entstanden.


    Netzteil wird also eine Art erweitertes PC Schaltnetzteil sein. Das ist etwas gefährlich, da dran rumzumachen. Eventuell herausfinden was für Spannung und Ströme die Kiste benötigt und durch ein oder mehrere neue Netzteile ersetzen.


    Aber auch auf dem Controller sehe ich Probleme. Da sind mindestens zwei Eproms (zwei Chips neben einander mit weißen Aufklebern drauf). Die könnten ihren Inhalt verloren haben.


    Ein paar von den Kondensatoren könnten Tantal Elkos sein, die könnten sich in Kurzschlüsse verwandelt haben.


    Drei Quarzoszillatoren sehe ich auch. Glaube die altern auch.


    Unschön finde ich die zahlreichen blauen 10-Gang Potentiometer. D.h. da muss irgendwas genau abgeglichen werden. Könnte die Ursache für die Probleme sein, von denen damals die Anwender sprachen. (Das ist jetzt auch schon 20 Jahre her, dass die mir das erzählt haben.)


    Das wird eher eine Elektronikbaustelle, als was mit Robotern ...