Beiträge von Urmel

    Noch ein Nachtrag:


    Das mit der Kaffeemühle meine ich nicht abwertend.


    Der RM-501 ist zwar nicht der erste Roboter von Mitsubishi (das war der RM-101), aber er war wohl der erste in größerer Stückzahl eingesetzte Kleinroboter.


    Er hat sicher einen ähnlichen historischen und ideellen Wert wie ein Commodore PET oder ein Apple ][ und stammt auch aus der gleichen Zeit. Auch ist er technisch so weit von seinen Nachkommen entfernt, wie diese Computer von heutigen PCs.


    Ob er allerdings auch einen finanziellen Wert hat, kann ich nicht sagen.


    Nun, wenn Du ihn verkauft hast kriegen wir hier bestimmt wieder einen neuen Thread über die Programmierung dieses Teils. :zwink:


    Grüße


    Urmel

    Hallo,


    ich glaube diese Frage ist ähnlich schwierig zu beantworten, wie die nach dem Marktwert einer handbetriebenen Kaffeemühle. ;)


    Der Roboter ist ein absolutes Sammlerstück. Wenn er wirklich noch fast neuwertig ist, könnte er etwas wert sein. Allerdings sind die meisten Leute, die sich noch damit beschäftigen Hobbybastler mit wenig Geld.


    Vor ein paar Jahren hat Mitsubishi immer welche gesucht, weil sie selber keinen mehr hatten.
    Frag doch mal an. :mrgreen:


    Grüße


    Urmel

    Hi,



    Von der Bedienbarkeit sollte mann sich überlegen ob ein Handling das genau für mein Anwendung entwickelt wurde nicht sowieso immer die Besser Wahl ist.


    Auf jeden Fall ist es besser für den Verkäufer. So sichert er sich eine langfristige Einnahmequelle, weil der Kunde bei Problemen mit der Speziallösung nicht einfach jemand anderes holen kann. :zwink:


    Grüße

    Urmel

    Hi,



    So, runterladen klappt, die Installation wirft ne Handvoll Fehler raus, das Programm läuft - bei mir - nicht.


    Also auf einem sauberen Windows XP in einer virtuellen Maschine klappt bei mir die Installation reibungslos in dieser Reihenfolge: 8)


    1. Visual C# Express
    2. .net-Framework 2.0 SDK
    3. Robotics Studio 1.0


    Robotic Studio installiert dann während des Setups noch AGEIA PhysX, das XNA-Framework und das .net-Framework 3.0 hinzu.



    Abgesehen von der sehr richtigen Satan-Assoziation hat Microsoft aber recht: Es gibt keinen vernünftigen Standard für das Programmieren von Robotern, der Markt ist zerstückelt. Ob Windows dafür die richtige Plattform ist (nein) oder Microsoft ein Wünschenswerter Hersteller sein mag (nein), steht auf einem anderen Blatt.


    Microsoft definiert ja deshalb auch ein XML-basiertes Netzwerkprotokoll als Schnittstelle.
    Für eine Linux-Implementierung müssen aber sicher andere sorgen. :twisted:


    Es gibt aber eine Open Source Software (kein .net) die einen ganz ähnlichen Ansatz verfolgt:
    http://playerstage.sourceforge.net/



    Ich hoffe eher auf so etwas wie es bei .NET passiert ist: Eine open-source implementierung, die man benutzen kann.


    Robotics Studio ist ja auch im wesentlichen eine Erweiterung von .net, also mehr ein SDK als ein Fertigprodukt wie Visual Studio. Roboterprogrammierung im Sinne von Microsoft ist, auf oberster Ebene, .net-Programmierung.
    Das Produkt ist also eher was für (fortgeschrittene) PC Programmierer, als für "echte" Roboterprogrammierer.


    Mit Robotics Studio erstellte Anwendungen sind keine einzelnen Windows-Programme, sondern ein Netzwerk miteinander kommunizierender Dienste. Wobei einzelne dieser Dienste, z.B. innerhalb von Sensoren, auch auf Mikrocontrollern implementiert sein können.


    Hier ein Link zu technischen Details:
    http://msdn.microsoft.com/msdn…rrentAffairs/default.aspx
    Sieht doch aus wie normale Roboterprogrammierung, gell. :mrgreen:


    Der Simulator unterscheidet sich relativ stark von den üblichen CAD-basierten Robotersimulationsprogrammen. Technisch steht er eher der Videospielprogrammierung nahe. Und wie schon gesagt, dass ganze basiert auf Vernetzung von Komponenten. Man muss da schon etwas in die Programmierung einsteigen, sonst passiert da nicht viel.


    Das Marksegment "Lego Roboter + passende Videospiele + Hobbyprogrammierer" dürfte auch ein wenig größer sein, als "Backsteine stapeln in der Fabrik". :zwink:


    Deswegen wird sich das ganze erstmal auf die Bereiche Forschung, Schule und Hobby konzentrieren. Danach vielleicht auf Haushaltsroboter und ähnliches.


    Der Industrieroboterbereich wird wohl zuerst in den PC nahen Bereichen, wie Laborautomatisierung, Messtechnik usw. davon berührt werden. Aber das kann, wie bei OPC, ein paar Jahre dauern.


    Was sich bei Kuka in dieser Richtung tut, wissen die Experten in diesem Forum bestimmt besser. Auf Fragen im Microsoft Forum, ob Robotics Studio auch bei anderen Modellen als dem Leichtbauarm unterstützt wird, wurde allerdings eher ausweichend reagiert.


    Grüße


    Urmel

    Hi,


    ich beobachte das schon seit den CTP-Versionen (Community Technology Preview), die im Sommer rauskamen.


    [Edit]
    Hier noch ein Link, zur Vorgeschichte:
    http://www.theregister.co.uk/2…20/robo_studio_microsoft/
    [\Edit]


    Allerdings habe ich es immer nur in einer VM getestet. Nie zusammen mit einem realen Roboter. Wenn alle Voraussetzungen installiert sind, d.h. mindestens eine Visual Studio Express Version und das .net-Framework 3.0, konnte ich zumindest einen Teil der Beispiele zum Leben erwecken.


    Den grafischen Simulator mit dem Kuka-Arm habe ich leider nicht zum Laufen gebracht. Andere
    Features wie die grafische Programmiersprache und die Sprachausgabe (sehr lustig :)) haben
    funktioniert.


    Mit der Final-Version habe ich mich aus Zeitgründen noch nicht beschäftigt.



    Der technische Ansatz ist auf jeden Fall sehr interessant. Es handelt sich um eine Übertragung von SOA (Service Oriented Architecture) auf Probleme der Roboterprogrammierung.


    Das bedeutet in der Praxis, dass alle Arten von Sensoren und Aktoren, aber auch ganze Roboter, Dienste darstellen, die über Netzwerk mit einander kommunizieren. So kann man lose gekoppelte verteilte Systeme entwickeln.


    Im Moment ist das wohl eher eine Plattform für die Forschung, insbesondere für mobile oder kooperierende Roboter. Wie man Echtzeit und Sicherheitsanforderungen industrieller Anwendungen damit befriedigen will, muss die Zukunft noch zeigen.


    Nützlich könnte das ganze werden als Universalschnittstelle für Sensoren. Quasi eine Art OPC für Roboter.


    Grüße


    Urmel

    Hallo,


    das Herstellen der Verbindung scheint bei den älteren Modellen wirklich ein Problem zu sein,
    nach dem was man so hier im Forum liest. ;)


    Mein Problem ist, dass der älteste Typ für den ich je Software geschrieben habe der RV-E2 ist.
    DIP-Schalter für die serielle Schnittstelle gab es da schon nicht mehr.


    Die seriellen Kabel haben sich seit damals nicht mehr geändert und funktionieren auch noch mit den
    aktuellen Modellen. Nur kann ich nicht sagen, ob die Belegung auch beim RV-M1 schon so war.


    Von der Aderbelegung ist es im Prinzip ein NULL-Modem-Kabel. Bei Conrad gab es mal einen
    25 poligen Null-Modem-Adapter. Wenn man den auf den Anschluss des Roboters steckt,
    kann man dann ein normales 1:1 Kabel mit 9-poligem Stecker an der PC-Seite und 25 pol. Stecker
    an der Roboterseite verwenden.


    Wie gesagt, das funktioniert bei allen Robotern seit der E-Serie. Vergleich mal in den Handbüchern,
    ob die Belegung beim M1 die gleiche ist.


    Null-Modem Kabel und Gender-Changer müsste eigentlich auch gehen.


    Zur Hardware können hier sicher andere mehr sagen ...


    Grüße


    Urmel

    Hallo,


    RobotComander hat das doch in seinem Posting beschrieben. :zwink::pfeif::blumen:


    Folge dem Link in seinem Posting zur Mitsubishi Homepage.


    Klicke in dem orangen Feld in der Mitte auf Downloads und wähle dann Typ=Handbuch Sprache=German Produktbereich=Roboter


    Das Buch das du brauchst ist ganz unten in der Liste, die dann erscheint.
    (RV-M1 Anwenderhandbuch (Scan))


    Grüße
    Urmel

    Hi,


    eine Möglichkeit wäre z.B. eine DLL in C++ zu schreiben und sie dann in VB aufzurufen.
    Damit konnte man VB6 sogar die Echtzeitsteuerung für den RV-E4 unterschieben. 8)


    Hast Du nur VB6 oder ein Visual Studio ? Da wäre ja C++ dabei ...


    Darf man fragen was das für ein Projekt ist ? Schule ?


    Grüße


    Urmel

    Hallo,


    man kann alle Mitsubishi-Roboter über über gängige PC-Programmiersprachen steuern.
    Dafür braucht man kein Cosirop.


    Allerdings geht das bei den älteren Robotern nicht in Echtzeit. Über die
    serielle Schnittstelle landet man quasi bei der Kommandozeile des Interpreters.
    Der braucht immer etwas um die Eingabe zu verdauen.


    Es ist bei diesem Roboter ähnlich wie bei alten Heimcomputern wie dem C64.
    Eine Befehlszeile mit Zeilennummer wird ins Programm gespeichert. Ohne
    Zeilennummer wird sie direkt ausgeführt.


    Details dazu sollten im Handbuch stehen.


    Was du als "stepXaxis(stepcount)" beschrieben hast, wird z.B. über die Befehle DW und MJ realisiert.


    Grüße


    Urmel

    Seufz,


    VB6 ist bei mir schon ein paar Jahre her. :kopfkratz:


    Ob man mit diesem MSComm-Control die Handshakesignale von Hand setzen kann,
    weiß ich leider nicht.


    Versuch mal


    MSComm1.DTREnable = True
    MSComm1.RTSEnable = True


    einzubauen. Vielleicht hilft das.


    Mehr kann ich mangels altem VB und passendem Roboter nicht sagen.


    Grüße
    Urmel

    Hi,


    nur damit keine Verwechslungen aufkommen:


    LPT1 ist die erste parallele Schnittstelle, COM1 die serielle.


    Hast Du den Roboter nun an die serielle (COM, RS232) oder parallele (LPT) Schnittstelle
    angeschlossen ?


    Was soll die Zeile "Mode LPT1:= COM1" bedeuten ? Die parallele Schnittstelle
    auf die serielle umlenken ? Geht das ? :kopfkratz:


    Ich glaube Du bringst da was durcheinander ...


    Zum Roboter kann ich leider nichts sagen, da must Du warten bis andere
    Fossilienfreunde hier vorbeischauen. :zwink:


    Grüße
    Urmel

    Hi,


    mit eigener OPC-Erfahrung kann ich zwar nicht dienen, habe mir allerdings
    einmal das hier angeschaut:


    http://www.opcconnect.com/


    Sollte als Ausgangpunkt helfen.


    Im Prinzip ist es ja normale COM (oder neuerdings wohl XML) Programmierung,
    also in VC++ ein Fall für die ATL oder #import. Das alte VB6 war für sowas sicher
    auch gut, aber ist doch schon 8 Jahre alt. Also wenn nicht C++, dann würde ich
    wohl eher C# (oder meinetwegen VB.net) nehmen.


    hope that helps


    Urmel

    Hallo,


    dafür gibt es das sogenannte R3-Protokoll. Das ist in der Tat nicht in den normalen Handbüchern
    beschrieben.


    Systemhäuser und Kunden, die PC-Anwendungen erstellen, können eine Doku direkt bei
    Mitsubishi erhalten. Wende dich dafür an den Händler, der dir den Roboter verkauft hat,
    oder an das zuständige Vertriebsbüro.


    Alternativ gibt es auch von Drittherstellern z.B. DLLs, die die entsprechende Funktionalität
    enthalten. Bei Bedarf kann ich hier mal einen Link posten.


    Grüße
    Urmel

    Hallo nochmal,


    hab gerade die Webseite gefunden, sind also Schweißroboter. Nein, tut
    mir leid, nie gesehen.


    Das mit den Scaras war Toshiba. Habe ich verwechselt.


    Grüße


    Urmel

    Hi,


    also ich war schon auf einigen Messen (Hannover, Motek, Automatica, ...),
    aber Panasonic habe ich noch nicht gesehen. :kopfkratz:


    Ich glaube Panasonic baut Servomotoren. Vermutlich verbauen sie die
    auch in eigene Roboter.


    Ist dein Roboter ein Scara ?


    Grüße


    Urmel