Beiträge von Urmel

    Hallo,


    ich denke mal, wir können den Thread hier lassen, das Thema ist ja relativ speziell.


    Vor Jahren habe ich mal was mit Stäubli und PC Steuerung gemacht und muss es demnächst wieder, so kann ich zumindest dazu etwas beitragen. Eigentlich arbeite ich mehr mit Mitsubishi und PC-Steuerung.


    Die Software heißt wohl aktuell Stäubli Robotics Suite. Man bekommt die bei Stäubli als kostenlose und als Kaufversion (Dongle). Der von dir erwähnte Simulator funktioniert nur in der Kaufversion. Die liegt irgendwo über 1000 Euro. Im Prinzip wird da eine Steuerung in einer virtuellen Maschine gestartet. Damit kann man die Kommunikation testen.


    Der Roboter kann recht gut über TCP/IP kommunizieren. UDP ging früher nur auf Umwegen, bei Bedarf den Support fragen.


    Die Programmiersprache kann sogenannte synchrone Tasks, das sind Programme, die einmal pro Interpolationstakt (normalerweise 4 ms) ausgeführt werden. Damit man den Roboter auch in 4 ms Schritten bewegen kann, braucht es die "Alter Option". Die kostet auch wieder um die 1000 Euro, man kann sie aber auch im Demo Modus freischalten. Dann läuft sie eine gewisse Zeit nach dem Kaltstart der Steuerung (2 Stunden ?). Im Simulator sind die 4 ms nicht exakt, hängt vom PC ab, reicht aber, um das Prinzip zu testen.


    Damit hast du quasi die "Game Loop" des Roboters. Den Rest kannst du nach Belieben gestalten.


    Der Support ist immer recht hilfsbereit. Die können dir sicher Doku und die kostenlose Software beschaffen. Optionen kannst du auch zu einem gebrauchten Roboter nachkaufen.


    Grüße


    Urmel

    Hallo,


    was Frage 1 angeht, ja der Markt ist völlig undurchsichtig. Gebraucht würde ich nur Robotern aus der eigenen Firma trauen, die ich kenne.


    Was Frage 2 und 3 angeht: Technisch ist das nichts wirklich neues. In diversen, auch deutschen, Nachrichtenstudios gibt es Kameras mit Industrierobotern als Stativ (hauptsächlich Stäubli). Schnelle Steuerung über PC ist aber bei vielen Herstellern Sonderaustattung. Die wird der gebraucht gekaufte Schweißroboter eher nicht haben. Das Projekt besteht dann eher daraus, die fehlenden Funktionen irgendwie zu ersetzen.


    Grüße


    Urmel

    Wie gesagt, der ist vierstellig.


    0601 bis 0606 wären kaputte Encoder, das wird es nicht sein.


    Also ist es wohl 6020. "The operation is disable" klingt plausibel in dem Zusammenhang. Keine Rechte zum Programmstart angefordert.


    Schlüsselschalter in der richtigen Stellung ?

    Wenn neueres Modell mit Schlüsselschalter mit zwei Stellungen, Parameter OPPSL richtig ?

    Müsste aber stimmen, wenn es über RT-Toolbox geht.


    1;1;CNTLON hat er vorher nicht angemeckert ?

    Stimmt, das gibt es tatsächlich. Kannte ich nicht.


    Aber dein Fehler kommt nach dem Senden des RUN ? Dann müsste ja so eine vierstellige Fehlernummer in der Antwort enthalten sein. Was sagt das Handbuch denn zu der ?

    Hallo,


    ich bin mir nicht sicher, ob Telnet das gleiche macht, wie ein normales TCP-Socket.


    Ein Terminalprogramm sendet die Daten möglicherweise zeichenweise, während du tippst. Das mag der Roboter nicht so, er kommuniziert normalerweise zeilenweise.


    Ansonsten, wenn Print funktioniert, würde auch sowas über Input funktionieren:

    Code
    Input #1,P1
    Mov P1

    Grüße

    Urmel

    Irgend ein Programm muss schon auf der anderen Seite sein.


    Und mit der Echtzeitsteuerung hat das jetzt eigentlich gar nichts mehr zu tu. Allerdings kann man es damit kombinieren, wie oben schon geschrieben.


    Die Ausgabe wird auch nicht so sein wie erwartet, weil das das Print schon während des Mov P1 ausgeführt wird.

    Hallo Peter,


    also auf TCP-Client habe ich noch nie einen Roboter eingestellt. Das bedeutet ja, dass auf dem PC ein Serverprogramm bereit zur Verbindungsaufnahme sein muss, wenn der Roboter die Verbindung aufbauen will. Da weiß ich schon mal nicht genau, wann der das macht. Diese Einstellung würde ich eher nehmen, wenn der Roboter sich z.B. mit einem über Ethernet verbunden Sensor, der immer da ist und gemeinsam mit dem Roboter eingeschaltet wird, verbinden soll.


    Das alte Visual Basic 5 Beispiel für die Data Link Kommunikation benutzt auch den Roboter als Server. Ein neueres Beispiel habe ich auch noch nicht gesehen. Die Bilder im Handbuch sehen immer noch aus, wie bei dem VB5 Beispiel für die Ethernetkarte für die RV-...A Roboter.


    Grüße


    Urmel

    Hallo,


    schön, dass es jetzt geht.


    Im Prinzip kannst du dir das so vorstellen, dass da zwei Programme parallel laufen. Eins auf dem PC und eins auf dem Roboter. Die PC Seite kann eigentlich alles sein, wo C++ läuft, auch Linux.


    Der Mxt Befehl ist dann im Roboterprogramm ein Platzhalter dafür, dass an dieser Stelle des Roboterprogramms der PC die Bewegung übernimmt. Nach Ende der Echtzeitbewegung geht das Roboterprogramm dann in die nächste Zeile.


    Das Beispiel zeigt halt nur das Prinzip der Funktion des Mxt Befehls. Als Grundlage für eine echte Anwendung ist es eher nicht gedacht.


    In der Praxis gibt es wohl zwei Ansätze:


    Man kann nur mit einem minimalem Roboterprogramm arbeiten, so wie im Beispiel. Das ist dann quasi nur ein verpackter Mxt Befehl. Aber auch da kommt man in die Situation, dass man das Roboterprogramm starten, stoppen oder auf Fehler prüfen will. Da muss man also auch noch ausbauen.


    Der komplexere Ansatz geht mit dem Roboter ein wenig so um, wie ein Server mit einem Client. Das Melfa Basic Programm wird vom PC generiert, auf den Roboter geladen und überwacht. Da kommen dann alle drei Netzwerkschnittstellen der Robotersteuerung zusammen (R3-Protokoll zur Steuerung und Download, Kommunikation über Print / Input im Melfa Basic und Mxt für Bewegungen).


    Grüße


    Urmel

    Hallo,


    ich habe das Beispiel schon ewig nicht mehr verwendet, ist ja auch mittlerweile ziemlich alt. Die Echtzeitsteuerung funktioniert aber immer noch so, mittlerweile mit 3,55 ms Takt.


    Es sollte doch aber möglich sein in Visual Studio mit einem leeren C++ Konsolenprojekt anzufangen und den Code einzufügen.


    Ich bin mir nicht sicher, was du mit "die Visual Studio Datein nicht gefunden" meinst.


    Grüße

    Urmel

    Hello,


    Okey i waiting your example codes thank you.

    I indeed found a litte program written with Microsoft Visual C++ 98 that can read or write program and position data to a RV-E2. This is a 6 axis robot (introduced in 1994) that sould have nearly the same controller. Only the format of the position data is different between robots with 4, 5 oder 6 axes.


    The code was written for a customer, so I am not allowed to post it here. But I can describe what it does.


    First with this serial communication that when i send the code, the robot to learn this or immidiatly do the command?


    Both. Think of the serial connection like you are working on a old home computer from the 1980s.


    You are working on a kind of command line and are sending complete lines, each terminated with a carriage return sign (CR, ascii code 13). On some commands that you send the robot will answer with a line itself.


    Some commands are only allowed inside a program, some only direct and not in a program. some commands are allowed in both. This should be described in the RV-E2 or RV-E3J programing manual, which should be free for download on the Mitsubishi website.


    For example if the robot is running and a position P1 is teached, sending a


    MO 1


    should directly start a motion to this position.


    On the other side downloading a program is like this (each line terminated with a CR)


    NW

    PC 1,999

    PD 1, .... (coordinates of position)

    PD 2, ....

    PD 3, ....

    DL 1,9999

    1 MO 1

    2 MO 2

    3 MO 3

    4 ED


    NW means "New program" (see manual)

    PC = position clear

    PD = position define. The format will be special to your robot, you will have to find out


    The MOs with leading line number will be stored as a program.


    The program can later be startet with RN (= run)


    So most of the commands used on the serial line can be found in the programing manual.


    Only reading teached positions out of the current program is a bit tricky and not described in the manual.


    EXE 0,"ElP<"

    will get you the first position in the current program.


    After that you can send

    EXE 0,"ElP+1"

    to read out the following positions, until a empty line appears.


    If there's am manual about this EXE codes, I don't have it.



    In the TB i see numbers 0 to 9 and two lines the IN and OUT.

    In this case i combinate the numbers the appropriate for the bit value when i write zero and one in this lines and thas same way for the outputs? Or if I think wrong, can you show me how it works with an example?

    The robot controller can have up to 3 expansion cards with digital IOs. Each having a 50 pin Centronics connector with the bits. The TB is only showing a part of them at a time. You should be able to set the start bit number of the showed sequence.


    There have been expansion cards with sink or source logic. You have to check what's inside your robot.


    There may be hand IOs, too. For this the controller needs a hand interface board (sink or source type).



    Hope that helps for a start


    Regards


    Urmel

    Hi,


    I think this robot model was never official sold by Mitsubishi in europe. Only a few machines appeared here as a part of machines imported from Japan. So it's likely that european software like Cosirop will not work correct with them.


    Programming the CR-E116 over a serial connection should be not much different from RV-E2 or RV-E3J robots. But there is not much official documentation about the communication protocol. Maybe I can find some examples in old source code.


    Regards

    Urmel

    welche Software würde denn den M2 ansteuern Urmel ?

    Fertige Software wäre natürlich schwierig, am ehesten noch ein altes Cosirop mit Parallelport Dongle, falls das auf aktuellen PCs läuft.


    Ansonsten läuft so ein Roboter eigentlich mit allen gängigen Programmiersprachen. Python, C# oder C++ wären z.B. geeignet. Man braucht nur ein passendes serielles Kabel.


    Kommunikationsprotokoll und Programmiersprache sind bei diesen alten Robotern ja qausi das gleiche. Schickt man einen Befehl ohne Zeilennummer davor, wird er sofort ausgeführt. (Ob das für einen Befehl erlaubt ist, steht im Handbuch.) Schickt man ihn mit Zeilennummer davor, wird er als Teil des Programms gespeichert. Mehr ist da eigentlich nicht.


    Im Prinzip verhält sich die Steuerung an der seriellen Schnittstelle wie ein 80er Jahre Homecomputer an der Tastatur.

    Hallo,


    doch per PC dürfte da auch sehr viel gehen, da haben wir hier Sachen für noch ältere Modelle. Das meiste, was es hier im Forum für den RV-M1 gibt, dürfte auch für dem M2 gelten.


    Aber ich habe in den über 20 Jahren, in denen ich PC Software für Mitsubishi Roboter entwickle, noch nie einen funktionsfähigen M2 gesehen. Nur kaputte. Der war wohl von der Hardware deutlich empfindlicher als der Vorgänger M1 und der Nachfolger E2.

    Hallo,

    von Mitsubishi gibt es zu der Karte und leider keine Aktuelle Doku somit sind wir etwas ratlos.

    das sind sicher seit 15 Jahren die gleichen Karten, kann höchstens sein, dass es mal Bauteil oder Platinenänderungen gegeben hat.

    normalerweise ist das nutzen der Karte einstecken Pins definieren und los geht's oder nicht ?

    Eigentlich nur reinstecken und los geht's. Die M_In und M_Out Variablen sind immer da, auch wenn keine Karte steckt. Diese IO Variablen Definitions Geschichte ist schon wieder was spezielles, wenn man Variablen haben will, die an IO-Bits gebunden sind.


    Die Karte sollte auch ganz ohne Programmierung funktionieren. Auf dem Handbediengerät und in der Programmiersoftware sollte man Ausgänge setzen können und Eingänge sollten angezeigt werden.

    Hallo,


    nein, in dem Controller steckt keine SPS im engeren Sinne. Technisch betrachtet ist das ein Echtzeitrechner, wohl mit einem Verschnitt des Betriebssystems VxWorks drauf.


    Es gibt allerdings Mitsubishi Roboter, wo die Steuerung mit einer Mitsubishi SPS kombiniert ist. Die haben aber eine andere Typenbezeichnung.


    Die IO-Bits gehören auch zu den Standardgeschichten und sind im Handbuch beschrieben. Siehe M_In, M_Out, usw.


    Grüße

    Urmel