Beiträge von Urmel

Hallo

Zitat von Nutzer47261

Ich habe nun zwei mantec R3 Roboter kaufen können mit rcm 2 Steuerung.

Du meinst Manutec ?

Sowas wie hier ? (Da steht 15 kg Traglast)
https://www.roboterforum.de/ro…verkauf-manutec-r3/10630/

Hallo,

also wenn in einer Doku kein aktuelles Modell der F-Serie auftaucht, ist sie sicher zu alt. Von Ausnahmen bei der Kollisionsüberwachung bei den F-Sechsachsern habe ich noch nichts gelesen.

Ich bin mir relativ sicher, dass wir diese Funktion schon bei einem 7FLL verwendet haben. Was kommt denn für eine Fehlermeldung ?

Grüße

Urmel

Es wird ein EPROM verwendet. In der hier im Forum befindlichen Anleitung sieht man, dass ein Sockel wie bei einem EPROM Brenner auf der Vorderseite der Steuerung vorhanden ist. SRAM gab es erst bei späteren Modellen.

Mit dem EPROM arbeitete man aber wohl nur im produktiven Betrieb. Solange man am Programm arbeitete, wurde es auf einem angeschlossenen Computer gesichert. Das ist der Betriebsmodus mit dem man heute noch damit arbeiten könnte.

Wenn ein EPROM vorhanden ist, muss es nicht kaputt sein. Es könnte auch benutzt sein. Dann muss man es mit einem EPROM-Löschgerät löschen ...

Hallo,

funktioniert der Roboter denn noch ? Der muss jetzt bald 40 Jahre alt sein.

Wenn er nicht mehr funktioniert, ist es wahrscheinlich das günstigste nur die Mechanik des Armes zu behalten und mit neuen Motoren und komplett neuer Elektronik weiterzumachen.

Wenn er noch funktioniert, ist nicht gesagt, dass das noch lange so ist. Die Motoren (haben die Kohlebürsten ?) und die Elkos der Leistungselektronik sind da sichere Ausfallkandidaten. Außerdem braucht der doch zu dauerhaften Speichern von Daten noch EPROMS, die mit UV-Licht gelöscht wurden. Solche ICs sind heute rar und teuer, falls sie noch funktionieren.

Bei späteren Modellen ist die Kommunikation zur Teachbox eine serielle (RS422). Keine Ahnung ob die beim RM-501 schon soweit waren. Ich bin mir nicht mal sicher, ob da schon ein Prozessor in der Teachbox ist. Es kommen ja nur Prozessormodelle in Frage, die um 1980 schon lieferbar waren. Das sind nicht viele.

Schau dir halt die Chips an, die da verbaut sind und versuch etwas darüber herauszubekommen. Kaum einer davon dürfte heute noch lieferbar sein.

Grüße

Urmel

Manchmal machen Leute ein "Retrofit" mit so alten Armen, wie mit anderen alten Maschinen auch.

Das wird aber bedeuten, dass man alles außer den tragenden Teilen des Armes wegschmeißt. Also neue Motoren, Getriebe und eine ganz neue Steuerung.

Das setzt aber einmal gewisse Fähigkeiten in Konstruktion und Mechanikfertigung voraus, weil man passende Motoren und Getriebe kaum finden wird. Da muss also geändert werden.

Billiger als der Kauf eines neuen Roboters ist das wohl in wenigen Fällen. Höchstens z.B. wenn Arbeitszeit nichts kostet, wie bei Studenten.

Das Ding wurde vor ungefähr 40 Jahren konstruiert. Da dürften nur Bauteile verbaut sein, die man nicht mehr kaufen kann und deren Dokumentation lange vor Entstehen des Internets geschrieben wurde.

Wenn man nicht gerade ein Computermuseum betreibt, macht es nicht wirklich Sinn sich mit dem Teil zu beschäftigen.

Hallo,

das klingt als ob der Inhalt des Speichers beschädigt wurde.

Wahrscheinlich wurde die Batterie entsprechend der Anleitung gewechselt. Das wird bei einem so alten Roboter, er muss ja schon um die 20 Jahre sein, nicht funktionieren. Die Spannung wird während des Batteriewechsels von einem Kondensator aufrechterhalten, der hat inzwischen so viel Kapazität verloren, dass das nicht mehr geht. Bei so einer alten Kiste geht der Batteriewechsel wahrscheinlich nur im eingeschalteten Zustand.

Wie dem auch sei, da muss der Service helfen. Das wird schwierig weil der Roboter seit langem abgekündigt ist. Ich denke man muss da einen Reset machen und den Armtyp neu einstellen, neu kalibrieren und dann die Programm neu draufladen.

Grüße

Urmel

Sollte alles gehen.

Beim Controllertausch bei neueren Modellen muss offiziell eigentlich mehr geändert werden, da ist ja z.B. auch die Seriennummer des Arms eingetragen. Ob die allerdings mehr als informativen Character hat, weiß ich nicht.

Hallo,

meines Wissens nach bleiben die Daten gültig, solange die Batterien im Arm ok sind.

Grüße

Urmel

Kommt drauf an was man machen will.

Plus nimmt man für relative Änderungen in Weltkoordinaten.

Mal eher für relative Beziehungen zu einem Objekt.

Werkstückkoordinaten wurden beim Mitsubishi erst in den letzten Jahren eingeführt. Es ging auch 20 Jahre ohne, alles mit +, -, *, / und Inv.

Hallo,

Zitat von Zvende81

Vielleicht hat jemand ein Beispiel wie sich bei der Multiplikation die Postion verändert.

ja, die Anleitung hat dazu Bilder, z.B. unter "Relative calculation of position data (multiplication)".

Kurzfassung:

Bei P1 + P2 werden die Elemente einzeln addiert.

Bei P1 * P2 bildet P1 den Ursprung eines Koordinatensystems, P2 die Koordinaten relativ dazu.

Beispiel P_Curr * (0, 0, 100, 0, 0 0) ist ein Punkt 100 mm in Tool-Z Richtung. (P_Curr ist die aktuelle TCP-Position.)

Grüße

Urmel

Also ich glaube das CallP ist so ein Relikt aus den alten Zeiten. Das gab es schon beim alten RV-E4NM in Melfa Basic III, also seit etwa 20 Jahren. Also aus der Zeit bevor es Multitasking in Melfa Basic gab.

Ich benutzte das gar nicht. Allerdings schreibe ich sowieso nur Codefetzen von Hand, die Hauptarbeit leistet bei uns ein selbstgeschriebener Codegenerator. Dessen Grundprinzip ist ein mit If ... Then ... Else aufgebauter Verteiler, der die Unterprogramme mit Gosub anspringt. (Select Case war in den ersten Versionen ziemlich buggy, deshalb verzichten darauf, damit der Code auch auf älteren Robotern läuft.)

Mir ist nicht so ganz klar, wie ein Programm aussieht, wo die Verschachtelungstiefe von Gosub nicht reicht. Werden die Unterprogramme immer wieder "unvorhergesehen" unterbrochen und nie beendet ? Dann sollte man vielleicht die Programmlogik etwas überdenken.

Grüße

Urmel

Zitat von INTERRUPT

glückwunsch zu den runden 1100 Beiträgen

Hach, wie die Zeit vergeht

Das include war auf einer Powerpoint Präsentation zur nächsten Generation (Nachfolger F-Serie). Aber möglicherweise würde es durch ein Softwareupdate auch auf SD und F kommen.

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.

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

Hallo,

mir ist da keine Möglichkeit bekannt.

Vielleicht kann man das Problem ja umgehen, in dem man das Programm anders strukturiert. Also Unterprogramme nur wechselt, wo der Arm sowieso steht. Oder auf CallP verzichten und z.B. GoSub oder XLoad verwenden.

Demnächst gibt es wohl auch noch ein "Include", das "fügt" andere Programmdateien in einer Zeile ein, ohne das Programm zu wechseln. Sowas würde dir wohl helfen.

Grüße

Urmel

Hallo,

man sollte die Positionskonstante auch direkt hinter das Mov schreiben können, also z.B. EXECMov (100, 200, 300, 0, 0, 0).

Grüße

Urmel

Hallo,

also manche Dinge funktionieren nur, wenn man sie in der richtigen Reihenfolge ausführt.

Als erstes wäre da schon mal der Schlüsselschalter. Um den Roboter zu steuern, muss der auf Auto (extern) stehen, wenn der Schalter drei Positionen hat, bzw. wenn der Schlüsselschalter nur zwei Stellungen hat, auf Auto und der Parameter OPPSL entsprechend eingestellt.

Ein Programm, das das Protokoll verwendet, sollte immer alle nötigen Schritte beim Verbinden und auch beim Trennen machen. Das ist wichtig, sonst gehen manchmal Dinge nur beim ersten Mal, oder erst wieder nach dem Neustart des Roboters.

Ich habe im Moment gar keine Code in der Nähe, folgendes ist also aus dem Kopf geschrieben ...

Nach dem Aufbau der Netzwerkverbindung

OPEN=Toolname
CNTLON
SERVO ON
PRGLOAD=Roboterprogramm

Irgendwas machen und wenn fertig wieder in umgekehrter Reihenfolge

SERVO OFF
CNTLOFF
CLOSE

Positionen gehören ja zu einem Roboterprogramm. Ein Mov P1 kannst du natürlich nur machen, wenn du auch das Programm geladen hast.

Wenn du korrekt im Programm bist, kannst du Melfa Basic Befehle mit dem EXEC-Befehl ausführen, also z.B. "1;1;EXECMov P1".
Man beachte: Kein Space zwischen EXEC und Code.

Programme laden ist etwas kompliziert, manchmal braucht man LOAD= manchmal PRGLOAD=. Wichtig sind dabei auch die Befehle SAVE, STOP und SLOTINT, das sind die unterschiedlichen Bedeutungen der STOP-Taste auf dem Controller, also Programm anhalten und speichern, oder auf Anfangsposition zurücksetzen.

Auch die Teachbox nutzt dieses Protokoll. Man kann auch die Bewegungstasten simulieren, das ist der JOG-Befehl, das ist eine andere Variante den Roboter direkt zu bewegen. Ist aber ein wenig tricky.

Richtig gut funktioniert aber nur die komplexe Variante: Aus dem PC-Programm heraus ein passendes Melfa Basic Programm generieren, mit dem Protokoll auf den Roboter laden und dann starten. Ggf. im Roboterprogramm eine zusätzliche Verbindung aufmachen und mit Print/Input über eine zweite TCP-Verbindung mit dem PC-Programm sprechen. Wenn das nicht genügt, kann man zusätzlich noch zum Mxt-Befehl greifen und seine eigene Bahnsteuerung machen.

EXEC und JOG sind eher was für eine eigene Teachsoftware, eher nichts für flüssige Roboterprogramm.

Ich hoffe das bringt schon mal ein paar Ansätze zum experimentieren. Man kann sehr viel mit dem Roboter vom PC aus machen, aber vieles findet man nur durch probieren heraus.

Grüße

Urmel

Hallo,

das Thema wird wohl in der Hälfte aller Beiträge in diesem Unterforum behandelt.

Daher hier nur kurz eine Zusammenfassung:

Es gibt dafür ein Textprotokoll, beschrieben in der Anleitung "Connection with personal computer [RS-232C/Ethernet]", Dokumentennummer BFP-A4288. Diese gibt es beim Mitsubishi Support. Nein, auf deren öffentlichen Handbuchserver liegt sie nicht. Nein, hier im Forum soll sie auch nicht verteilt werden.

Grundprinzip:

Man sendet eine Zeile und erhält eine Zeile als Antwort. Die nächste Zeile darf man erst senden, wenn die Antwort gekommen ist. Die Zeilen werden normalerweise mit dem Zeichen "Carriage Return" (Ascii Code 13) abgeschlossen.

An den Roboter gesendete Zeilen haben die Form
Zifffer;Ziffer;Befehl Parameter
mehr dazu in der Anleitung

Eine Antwort vom Roboter beginnt mit

QoK = Befehl verstanden und ausgeführt
Qok = Befehl verstanden, aber kleineres Problem
QeR = Befehl verstanden, aber ungültig
Qer = nix verstanden

Bei Qer oder QeR sind die ersten vier folgenden Ziffern die Fehlernummer, genauso wie auf den Display des Roboters. Siehe Handbuch "Troubleshooting".

Grüße

Urmel