Ansteuern über C#

  • Hallo,


    ich (Student) soll einen RV-3SB über C# ansteuern. Dass dies über Ethernet anscheinend möglich ist, habe ich bereits rausbekommen. Weiß jemand wie das dann genauer abläuft, wenn ich die Ansteuerung dann über C# realisieren möchte?


    Danke schon mal!

  • ANZEIGE
  • Danke. Das Forum habe ich bereits "durchgelesen". Ich dachte zunächst, dass ich ne Library einbinden muss, aber im Prinzip ist dies ja einfacher als ich dachte :) Werde mich mal nun daran versuchen.

  • Hallo,


    folgende zu bewältigende Aufgabe hätte ich: Den Robocontroller über LAN so ansprechen, dass er ein dort vorhandenes Programm startet. Ich stelle mir da etwas vor à la 'starte Programm XYZ'. Eventuell noch einen Austausch vom Fehlerprotokoll etc. sprich 'gib mir Rückmeldung über Fehler'.


    Im Ethernet Handbuch bin ich bisher nicht so schlau draus geworden... wäre über n Tipp dankbar!

  • Hallo,


    wie schon im zweiten oben verlinkten Thread erwähnt, gibt es dafür eine eigene Beschreibung.


    Im Gegensatz zu ihrem Gegenstück für die SPS-Kommunikationsprotokolle ist sie nicht frei verfügbar, sondern nur auf Anfrage erhältlich. :???:


    Grüße


    Urmel

  • Hallo,


    nun ich habe heute auch u.a. mit dem Support telefoniert und fand das jetzt net sooo berauschend. Ich solle doch nen Netzwerküberwacher probieren und schauen was zum Roboter gesendet wird => dies abfangen und fertig. Nur kann's das doch nicht sein, zumal eine existierende Beschreibung wesentlich hilfreicher wäre. Hat die ne besondere Bezeichnung / Nummer oder ähnliches?
    (Angerufen habe ich bei dieser Nummer im Handbuch).


    Danke schon mal! :)

  • Nun, als Systemhaus oder Kunde, der regelmäßig Roboter kauft, hat man in der Regel feste Ansprechpartner an die man sich wenden kann.


    Bei der Hotline hängt es sicher davon ab, an wen man da gerät.


    Der normale Ansprechpartner wäre eigentlich der Verkäufer des Roboters, also entweder ein Händler oder eines der drei Vertriebsbüros (Dortmund, Filderstadt, irgendwas in Bayern).


    Der Name des Dokuments (es ist kein echtes Handbuch) steht oben im Link. Die Dokumentennummer (von Mitsubishi Japan) ist BFP-A4288-K.

    Einmal editiert, zuletzt von Urmel ()

  • Noch eine Frage (nachdem nun die Kommunikation mittels R3-Protokoll fantastisch funktioniert):


    Wenn ich dem Roboter 1;1;CNTLON dann 1;1;PRGLOAD=INIT und dann 1;1;RUN schicke dann fährt er das Init-Programm ab. Nur führt er das Init so lange durch, bis ich ihn durch 1;1;STOP zum aufhören überrede (ansonsten klackert er munter, fröhlich weiter). Ist das normal, bzw. kann ich ihm nicht sagen, dass er nach dem Init normal aufhören soll?

  • Hallo,


    das mit dem Wiederholen ist ganz allgemein so und lässt sich über Parameter einstellen. Hier gab es auch schon mal einen Thread dazu.


    http://www.roboterforum.de/rob…lfa_basic_iv-t3667.0.html


    Ein Problem was ich damit schon öfter hatte, ist das er diese manchmal wieder auf die Standardeinstellung (Wiederholen) zurückstellt, weswegen das etwas unsicher ist.


    Alternativ mach einfach deinem Programm "einen Knoten ans Ende" z.B. 100 GOTO 100 und stoppe es dann wieder über das Protokoll.


    Grüße


    Urmel

  • Danke, aber dann stellt sich wieder das Problem, dass ich den Zeitpunkt festlege, wann ich den STOP Befehl sende. Das ganze soll automatisiert ablaufen, d.h. nach dem Durchlauf auf wirklich stoppen (und dann programmintern an eine anderer Einrichtung weitergehen). Mit der Schleife könnte ich ja lediglich im vorhinein die Laufzeit abschätzen und dann nach der fixen Zeit den Stop-Befehl senden. Allerdings - wenn mal die Geschwindigkeit umgestellt wurde - geht das wieder schief :huh: :kopfkratz:


    Edit: Ich probier's jetzt mal mit der HLT-Lösung im Programm selbst.

    Einmal editiert, zuletzt von Sethmuc ()

  • Hallo Urmel,


    du hast in einem anderen Thread geschrieben, dass du die zweite Verbindung mit ausgeschaltetem Protokoll verwendest. Schaltest du dies manuell aus, so dass Befehle nicht interpretiert werden oder benutzt du auf der zweiten Verbindung schlicht keine Befehle - eben nur die PRINT-Befehle?


    Das mit dem HLT klappt wunderbar (Modul war auf CYL, hat aber dennoch wiederholt - angeblich nicht ganz so erklärbar das Phänomen). Wie mache ich denn eine zweite Verbindung auf TCP-Basis auf? Mit OPEN...as "COM.." öffne ich nur eine COM-Verbindung. Lässt sich auch ein bestimmter Port roboterseitig aufmachen? Sprich idealerweise würde ich gerne den (aktuellen) Port: 9002 als Befehlsport und einen 900x-Port als Input-Output-Austauschport verwenden.


    (Ich hoffe ich nerve nicht allzu sehr :))

  • Hallo,


    du must im Prinzip so vorgehen, wie in dem VB5-Beispiel im Handbuch:


    Wenn du jetzt auf Port 9002 arbeitest, hast du ja schon den NETPORT Parameter gefunden und verstellt.
    Da stehen normalerweise 9 Portnummern drin, der erste ist der UDP-Port für die Echtzeitsteuerung (überhaupt das beste am Roboter :mrgreen:) und dann acht TCP-Ports.


    In Melfa Basic werden TCP-Ports wie serielle Schnittstellen angesprochen. An einfachsten ist es, wenn der PC die Verbindung startet (Client) und der Roboter sie annimmt (Server).


    Um z.B. COM3 an den vierten Eintrag in NETPORT zu binden (normalerweise 10003), wird der Parameter COMDEV auf RS232,,OPT13,,,,, geändert. Der enthält die Zuordnungen für COM1 bis COM8.


    Jetzt kannst du den Comport schon in Melfa Basic benutzten, alles was dort ankommt wird allerdings als R3-Protokoll-Befehl interpretiert. Um das Protokol zu tunneln und die Eingabe an ein INPUT weiterzuleiten, muss man vor jede Zeile ein PRN schreiben. Das ist merkwürdigerweise der PRINT-Befehl aus dem Melfa Basic Vorgänger Movemaster Command.


    Man kann auch das R3-Protokoll für COM3 ausschalten, in dem man CPRCE13 auf 2 setzt, dann gehen alle Eingaben direkt in den Eingangspuffer für das INPUT.


    Der Rest ist im englischen Ethernethandbuch eigentlich ganz brauchbar beschrieben.


    Grüße


    Urmel

    Einmal editiert, zuletzt von Urmel ()

  • Hallo,


    die Portangaben habe ich mir aus Factorycontrol rausgeklaut. Habe aber nun den NETPORT richtig gesetzt und in meinem Beispiel bei COMDEV auf RS232,OPT13,,,,,, geändert. Somit ist jetzt (hier) Port 9003 an COM2 gebunden.
    Habe dann über Cosimir Pro ein kleines MB4-Testprogramm gestartet, welches eigenlich nur aus OPEN "COM2:" AS #1 und mit anschließendem PRINT #1,"TEST" besteht. Gleichzeitig bin ich mit meinem C#-Programm auf entsprechendem Port 9003 verbunden und versuche über netstream die Nachricht TEST abzufangen. Klappt aber irgendwie gar nicht.
    Mein Test habe ich bisher nur einmal erhalten und zwar wenn ich mit meinem Prog mich über Port 9003 verbunden habe und von da aus das Programm gestartet habe - da kam das dann auch an.


    Praktisch wäre aber: Ich bin mit nem anderen Port verbunden, starte das Programm und ne andere Instanz von meinem Prog überwacht den Port 9003 und kriegt dann irgendwann die Nachricht.


    Achso, außerdem war der Robo desöfteren auch nicht mehr ansprechbar - musste stets durch nen Reboot gelöst werden.


    Viele Grüße,

  • Ist wahrscheinlich ein Timing-Problem. Wenn keine Verbindung zum PC besteht, tut das PRINT vermutlich gar nichts. Wenn danach ein END steht, macht er die Verbindung sofort wieder zu.


    In der Regel mache ich das so, dass ich mit einem Thread über das R3-Protokoll das Programm lade und starte.
    Die positive Antwort auf das Starten ist das Signal für einen zweiten Thread, ein Connect auf den zweiten Port zu machen und auf Daten zu warten.


    Das Roboterprogramm macht am Anfang ein OPEN dann diverse Initialisierungen, meldet sich dann mit einem PRINT beim PC und wartet mit einem INPUT auf eine Antwort.


    Wenn sich der Controller aufhängt, machst du irgendwas falsch. So was kam eigentlich nur bei den alten Arcnetkarten oder den ersten Ethernetkarten mit D, E oder F Softwarestand vor.


    Grüße


    Urmel

  • Hallo Urmel,


    ich habe mein Programm nun Eventgesteuert kreiert. D.h. sobald irgendwas auf dem Statusport (also meiner zweiten Verbindung) reinkommt, wird dies für mich zu Testzwecken in einer Textbox dargestellt. Zu Testzwecken habe ich lokal 2 Server aufgemacht und "per Hand" Nachrichten auf einen bestimmten Port geschickt und siehe da - mein Programm funktioniert.
    Nur.. beim Roboter bin ich am verzweifeln. Nach wie vor kann ich auf meinem Kommunikationsport mir auch ne Nachricht schicken aber auf meinem Statusport kommt nix an.


    Könntest du bitte - wenn's keine allzu große Mühe macht - einfach mal mein angehängtes Prog mal testen? Ich kann mir nicht vorstellen, dass es am Prog liegt nur an die Parameter-Einstellungen inkl. COMDEV müssten auch passen.


    *help* :huh:

    Einmal editiert, zuletzt von Sethmuc ()

  • Hallo,


    ich bin leider im Moment sehr beschäftigt, wenn ich Zeit habe schaue ich mal ins Programm.
    Zum Testen an einem Roboter werde ich in den nächsten Tagen nicht kommen.


    Wenn die Kommunikation mit dem R3-Protokoll funktioniert und du nur schauen willst,
    ob dein Programm fertig ist, kannst du ja bei der Methode mit dem HLT bleiben.
    Mit 1;1;STATE oder 1;1;DSTATE sollte man ja sehen können, ob das Programm steht.


    Grüße


    Urmel

  • Hallo Urmel,


    es läuft doch alles perfekt. Habe nur vergessen den Parameter CPRCE?? richtig zu setzen (nämlich auf 2: Data-Link), so dass natürlich nix bei mir ankam.
    Stundenlanges Testen und dann ein Parameter... that's life!


    Danke für die Tipps! Jezt müsste alles wunderbar klappen. *FREUDE*

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden