Ich wollte mal nachfragen wer schon mal mit einen Mitsubishi RV Modell eine Echtzeitsteuerung ausprobiert hat, und wie sein Erfahrungswerte damit sind. Kleine Anwendungsbeispiele wären nicht schlecht.
Gruß
Fallon
Ich wollte mal nachfragen wer schon mal mit einen Mitsubishi RV Modell eine Echtzeitsteuerung ausprobiert hat, und wie sein Erfahrungswerte damit sind. Kleine Anwendungsbeispiele wären nicht schlecht.
Gruß
Fallon
Hallo,
da kann ich mit einiger Erfahrung dienen.
Typische Anwendungen bei uns: Kraft-Momenten-Sensorik, Abstandsregelung während der Bewegung, Bildverarbeitung, usw.
Beispiele in C++ posten ist etwas schwierig, die kriegen nur zahlende Kunden.
Aber du kannst gerne Fragen stellen.
Wie sieht es auf der PC-Seite bei dir aus ?
Windows oder Linux ?
Visual Studio, C++ Builder, oder was anderes ?
Programmierkenntnisse vorhanden ?
Grüße
Urmel
Hier mal ein Minimalbeispiel, basierend auf meiner Demosoftware, nicht auf dem Beispiel aus dem Handbuch:
Das Roboterprogramm
10 OPEN "ENET:192.168.0.2" AS #1
20 SERVO ON
30 WAIT M_SVO(1) = 1
40 MXT 1,0,0
50 SERVO OFF
60 CLOSE
70 GOTO 70
80 END
und ein minimales Windows (Konsolen-) Programm
int _tmain(int argc, _TCHAR* argv[])
{
try
{
// Initialisierung
CRealtimeControl Robot("192.168.0.1");
POSE p;
Robot.InitWorldData(p);
for(int i = 0; i < 10; i++) // Zehn Schritte a 0.1 mm
{
p.w.x += 0.1f;
Robot.MovePose(p);
}
// Ende der Bewegung
Robot.FinalWorldData();
}
catch(ERealtimeException &e)
{
cout << "Error : " << e.what() << endl;
}
catch(EBlockingSocketException &e)
{
cout << "Error : " << e.what() << endl;
}
catch(...)
{
cout << "unbekannter Fehler" << endl;
}
return 0;
}
Alles anzeigen
Das ganze bewegt den Roboter um 1 mm in +X vorwärts, in zehn Schritten zu 0.1 mm.
Mmh,
ich versuche gerade einen RV-1A mit einem Miitsubishi FX3u SPS mitsamt FX3u-ENET ueber Ethernet zu kontrollieren,
und blick es ueberhaupt nicht.
Die Verbindung zwischen SPS und CR1, dem Roboter-Kontroller, steht. Ich weiss allerdings nicht, wie ich nun vom SPS aus den Roboter steuern kann.
Irgendwer eine Idee?
Hallo,
was willst du denn genau machen ?
Das obige Beispiel ist eigentlich dafür gedacht den Roboter alle 7 Millisekunden aus einem in C++ geschriebenen PC-Programm anzusteuern.
Ich bin nicht sicher, ob das so auch mit einer SPS möglich ist.
Speziell wegen der unterschiedlichen Byteausrichtung (siehe http://de.wikipedia.org/wiki/Little_Endian ) zwischen SPS und PC.
Auch sind in diesem Modus Positionen, die über die Teachbox angelegt wurden, nicht direkt verwendbar. Die gesamte Bewegungsplanung muss das C++-Programm machen. Bin nicht sicher, ob du wirklich so was vorhast...
Eventuell ist eine der beiden anderen Möglichkeiten der Ansteuerung über Ethernet besser geeignet:
http://www.roboterforum.de/rob….0.html;msg19179#msg19179
Grüße
Urmel
Hallo,
ich weiß, dass das obige Programm dazu gedacht ist, das C++-Programm zu belauschen, das MELFA-Programm auf dem Roboterkontroller funktioniert aber auch so.
Ich versuche quasi, den Roboter extern zu steuern, und zwar mit einem SPS, wie man ja schon lesen konnte.
Ich weiß, dass wenn ich ASCII-Befehler ueber die Ethernet-Schnittstelle sende, der Roboterkontroller diese umsetzen kann.
Die Netzwerkkarte im CR1 kann man ja als COM- oder Ethernet/IP-Karte konfigurieren.
Meine Idee ist: ich lerne dem Roboter mit der Teachbox alle Positionen und rufe diese dann quasi extern mit dem SPS auf, so dass sich der RV-1a dann zu diesen bewegt.
Ich weiß, dass es funktioniert, ich habe es auch gesehen. Ich kann den Roboter auch vom PC aus ueber ENET steuern, auch die SPS, aber ich suche quasi nach einem Programm, welches den Roboter eben durch die SPS steuert.
Quasi wie hier: http://www.roboterforum.de/rob….0.html;msg10203#msg10203
Allerding will ich das, was du vom PC via C sendest, per ASCII von der SPS machen.
Es funktioniert über die Fixed Buffer Communication-Schnittstelle, das weiss ich.
Ich muss kurz anmerken, mein Deutsch ist nicht mehr das Beste: ich lebe in den USA.
Hallo,
ich weiß, dass das obige Programm dazu gedacht ist, das C++-Programm zu belauschen, das MELFA-Programm auf dem Roboterkontroller funktioniert aber auch so.
Nein, das C++-Programm ist in diesem Fall das Roboterprogramm. Der Basic Befehl MXT steht für Move External, d.h. die Kontrolle über die Bewegung wird an einen externen PC übergeben.
Zitat von MistaBishiIch versuche quasi, den Roboter extern zu steuern, und zwar mit einem SPS, wie man ja schon lesen konnte.
Ich weiß, dass wenn ich ASCII-Befehler ueber die Ethernet-Schnittstelle sende, der Roboterkontroller diese umsetzen kann.
Das ist richtig, aber das geht nicht so wie oben in dem Beispiel, sondern wie in diesem:
http://www.roboterforum.de/rob…oboter_rv3sb-t3878.0.html
Das sind die gleichen Befehle, die auch die Teachbox benutzt.
Zitat von MistaBishi
Die Netzwerkkarte im CR1 kann man ja als COM- oder Ethernet/IP-Karte konfigurieren.
Die Netzwerkkarte kann TCP/IP (OPEN "COMx" AS ...) und UDP (OPEN "ENET..." AS ...). Letzteres funktioniert nur in Verbindung mit dem MXT-Befehl.
Ethernet/IP ist etwas anderes (sowas wie EtherCAT, Profinet oder ModbusTCP). Das kann der Roboter nicht.
Zitat von MistaBishi
Quasi wie hier: http://www.roboterforum.de/rob….0.html;msg10203#msg10203
Ich habe dort geschrieben, es gibt drei Wege den Roboter über Ethernet zu steuern. Dort wird Methode 1 verwendet. Was du suchst ist Methode 2 und was hier oben in dem C++-Beispiel steht ist Methode 3.
Zitat von MistaBishi
Es funktioniert über die Fixed Buffer Communication-Schnittstelle, das weiss ich.
Ja das ist richtig. Das funktioniert mit den Befehlen aus der Anleitung "Connection with personal computer [RS232/Ethernet]".
Zitat von MistaBishi
Ich muss kurz anmerken, mein Deutsch ist nicht mehr das Beste: ich lebe in den USA.
Ist schon ok.
Grüße
Urmel
Danke Urmel,
ich lese mir das jetzt nochmal genauer durch.
Wir haben hier gerade Schneesturm, hab also eh nichts zu tun, den bei 40cm Neuschnee geht hier nichts, und es will auch keiner ausm haus.
Danke Urmel für deine Antwort. Ich selbstpersönlich habe nicht so den Durchblick über C-Programmierung, das macht aber auch ein Kollege. Er hat unabhängig ein Proggi geschrieben, was deinen da oben sehr nah kommt (unterLinux). Dazu noch einige Fragen:
Deine Demosoftware, was kann sie und kann man sie bekommen/erwerben?
Weitehin eine Verständnisfrage:
Bei einen Mov-Befehl kennt der Robbi die Entfernung und die Geschwindigkeit, und legt somit die Beschleunigungs und Brems-Flanken fest. Bei Cont-Befehl fährt er alle Punkte in einer fliessenden Bewegung ab.
Laut unseren Informationen versucht der Robbi bei Echtzeitsteuerung den nächsten Punkt in 7ms anzufahren. Da er den nächsten Punkt noch nicht kennt, beschleunigt er voll, geht dann voll in die Bremsen, beschleunigt wieder u.s.w. Das kann doch auf Dauer nicht sehr verträglich sein. Da unsere Anwendung bei sehr schneller Fahrt durchgeführt werden, ist das sehr belastend für den Robbi.
Ist die Echtzeitsteuerung nur bis zu gewissen Geschwindigkeiten sinnvoll, oder kann ich den gesammten Geschwindigkeitsbereich nutzen?
Wie bekommt man das Timing-problem gelöst, bei unseren Test hatten wir immer kleine Ruckler drin. Beim schweissen stört das nicht sonderlich, aber schon bei der Bildverarbeitung.
Über einen Denkanstoss wäre ich sehr dankbar.
Gruss
Fallon
PS:
Allen ein frohes neues Jahr
Hallo Fallon,
auch von mir ein gutes neues Jahr.
Zu deinen Fragen:
Der MXT-Befehl arbeitet im Prinzip wie die anderen Bewegungsbefehle (MOV, MVS, usw.) auch. Nur das der Roboter nicht selber die Bahn berechnet, sondern während er einen Schritt ausführt das Ziel für den nächsten Schritt holt.
Insoweit ist eine MXT-Bewegung schon eine gleichmässige Bewegung, wie eine andere Bewegung auch.
Theoretisch sollte man also den ganzen Geschwindigkeitsbereich nutzen können, bei unseren kraftgeregelten Systeme bleiben wir aber eher im langsamen und mittleren Bereich.
Es gibt auch bei der Echtzeitsteuerung so etwas wie den CNT-Befehl. Und zwar ist das die Filterkonstante, der dritte Parameter im MXT-Befehl.
Zu meiner Demosoftware:
Wir verkaufen ein Produkt namens RobCommand
http://www.battenberg.biz/content/DE/SW_RobCommand.html
Das ist eine DLL für Visual C++, die die ganze Ethernet-Kommunikation mit dem Roboter kapselt.
Standardmässig allerdings nur Data-Link und R3-Protokoll.
Optional gibt es auch die Echtzeitsteuerung dazu und für die Schulung dafür gibt es das Demoprogramm.
Einzeln haben wir die Echtzeitdemo eigentlich nicht im Angebot, es ist schwierig mit solcher Software Geld zu verdienen. Wir ziehen den Komplettverkauf von Hard- und Software vor.
Was das Ruckeln angeht, so tritt das unter Windows normalerweise nicht auf, es sollte also unter Linux eigentlich auch nicht passieren. Vermutlich ist das C-Programm noch nicht ganz so, wie es sein sollte.
Schau dir das Video zu RobPoint auf der obigen Webseite an, das basiert auch auf der DLL und ruckelt nicht.
Auch die Kraftkurven in den anderen Beispielen dort sind mit MXT gemessen. Die sähen anders aus, wenn etwas ruckeln würde.
Grüße
Urmel
Fehler gefunden. Es war einfach ein Timingproblem. Es wurden Daten verschluckt, dadurch wurden die Sprünge der Einzelschritte unterschiedlich gross, die der Robbie verarbeiten konnte.
Trotzdem vielen dank für deine Bemühungen.
Gruss
Fallon
OK, dieser Thread ist schon etwas älter, und die ursprüngliche Frage wurde nicht komplett beantwortet. Also, ich habe einen RV-3SB an einer CRn-500 (Software Version K9), und dann per TCP/IP Karte an einen PC verbunden. Zum Anfang habe ich die IPs so gesetzt wie im Manual vorgeschlagen (Controller: 192.168.0.1 und PC: 192.168.0.2). So, dann habe ich das Programm aus dem Mitsubishi Manuel zur RTC kompiliert und das tut nicht. Also habe ich mich mal reingehängt und ein kleines C# Test-Programm geschrieben (siehe unten). Läuft soweit, kann Port öffnen, kann mein Command raus senden aber erhalte vom Controller immer die Antwort „81, 101, 82, 54, 48, 49, 48, 48, 48, 48, 48, 48“, als String „QeR601000000“ und Roboter bewegt sich nicht.
Byte[] data = new Byte[196];
data = StructureToByteArray(txData); //txtData contains MXTCommand
TcpClient client = new TcpClient("192.168.0.1", 10001);
NetworkStream stream = client.GetStream();
stream.Write(data, 0, data.Length);
Byte[] indata = new Byte[196];
Int32 bytes = stream.Read(indata, 0, indata.Length);
Auf Urmel's Anregung hin habe ich dann den TCP-Teil geändert, was aber auch erfolglos blieb. Der Controller antwortet nicht:
Byte[] data = new Byte[196];
data = StructureToByteArray(txData); //txtData contains MXTCommand
IPHostEntry hostEntry = Dns.GetHostEntry(Dns.GetHostName());//"192.168.0.2");
IPEndPoint server_endPoint = new IPEndPoint(IPAddress.Parse("192.168.0.2"), 10001);
IPEndPoint remote_endPoint = new IPEndPoint(IPAddress.Any, 0);
Socket s = new Socket(AddressFamily.InterNetwork,
SocketType.Dgram,
ProtocolType.Udp);
s.Bind(server_endPoint);
s.SendTo(data, 0, data.Length, SocketFlags.None, server_endPoint);
data = new Byte[512];
data[0] = 0;
EndPoint ep = (EndPoint)remote_endPoint;
s.ReceiveFrom(data, ref ep);
s.Close();
Alles anzeigen
Hat jemand einen Hinweis wo ich weiter suchen kann?
Danke und Gruss!
Markus
Hallo,
ich bin mir nicht sicher, ob du das Prinzip der Echtzeitsteuerung wirklich verstanden hast.
Die Echtzeitsteuerung und der UDP-Port sind nur zugänglich, wenn der Roboter gerade einen Mxt-Befehl ausführt. Sonst antwortet der Roboter nicht. Du solltest also sicherstellen, dass sich der Roboter in einem laufenden Programm an diesem Befehl befindet.
Dieser Port ist normalerweise nicht der Port 10001. Normalerweise ist es die 10000, allgemein der erste Eintrag im NETPORT-Parameter.
Außerdem kannst du nicht, wie in dem Code in der PM, einfach einen Move-Befehl schicken. Siehe Beispiel im Handbuch (Kommentar "Only first time"). Du fängst mit einem MXT_CMD_NULL Paket an. Die eigentliche Bewegung findet dann in einer Schleife statt (in einem richtigen Programm innerhalb eines Threads), die immer wenn ein Antwortpaket vom Roboter eintrifft, den nächsten Schritt sendet. So sorgt der Roboter selbst dafür, dass das externe Programm den Takt hält. Das Senden eines MXT_CMD_END Paketes führt dazu, dass der Robotertask den Mxt-Befehl verlässt und im Programm weiter macht.
Die Bewegung die in einem Paket gesendet wird, muss so kurz sein, dass der Roboter sie in einem Echtzeitschritt (7.1 oder 3.55 ms) schafft. Ein Programm, das nur einen Befehl sendet, macht in soweit nur zu Testzwecken Sinn.
Willst du den Roboter mit einem Befehl über eine längere Distanz schicken, macht ein Roboterprogramm mit Tcp-Schnittstelle oder der JOG- oder EXEC-Befehl aus dem R3-Protokoll mehr Sinn.
Grüße
Urmel
Danke fuer den Hinweis. Also, dies sind meine Parameter:
NETIP: 192.168.0.1
NETHSTIP (OPT11): 192.168.0.2
NETMODE (OPT11-19): 1
NETPORT (OPT11): 10000
Auf dem Controller laeuft:
10 OPEN "ENET: 192.168.0.2" AS #1
15 SERVO ON
20 MOV PHOME
30 MXT 1,0
40 MOV PHOME
50 CLOSE #1
55 SERVO OFF
60 HLT
70 END
Ich habe versucht ein MXT_CMD_NULL zu senden, und dann ein MXT_CMD_END. Die Meldungen werden nicht abgeholt, und der Controller antwortet nicht, resp. beendet das Program nicht.
Byte[] data = new Byte[196];
Byte[] inData = new Byte[512];
IPEndPoint server_endPoint = new IPEndPoint(IPAddress.Parse("192.168.0.2"), 10000);
IPEndPoint remote_endPoint = new IPEndPoint(IPAddress.Any, 0);
EndPoint ep = (EndPoint)remote_endPoint;
Socket s = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
s.Bind(server_endPoint);
data[0] = 0; //send Null
s.SendTo(data, 0, data.Length, SocketFlags.None, server_endPoint);
s.ReceiveFrom(inData, ref ep);
data[0] = 255; //send Null
s.SendTo(data, 0, data.Length, SocketFlags.None, server_endPoint);
s.ReceiveFrom(inData, ref ep);
s.Close();
Alles anzeigen
Nun habe ich keine weiteren Ideen. Noch was zum Hintergrund. Ich plane den Arm mit einem Kinect-Sensor zu steuern, damit Besucher mit dem Arm interagieren koennen... daher RTC...
Hm,
wäre was angekommen, hätte er entweder geantwortet oder gepiepst, es gibt eine eigene Fehlermeldung für falsche Echtzeitdaten.
Ich habe meinen Code nicht hier, aber ich meine du machst beim UDP was falsch.
Wenn dein Roboter die ...0.1 ist, musst du an diese Adresse und Port 10000 senden. Die Adresse im Roboterprogramm ist die, an die er antwortet, also die des PCs. Da stimmt schon mal was nicht.
Normalerweise verwende ich auf dem PC implizites Binding, unter C# glaub ich einfach den UdpClient nicht umständlich mit Socket, d.h. ich lege den Port auf dem PC nicht explizit fest.
Das ganze ist nicht wirklich schwierig, nur ein Ping-Pong Spiel über UDP.
Für die Kinect macht das schon Sinn damit zu arbeiten, das ist allgemein üblich. Gibts schon diverse Videos z.B. von der TU-München auf YouTube.
Grüße
Urmel
Edit: Ungefähr so
// Initialisierung
IPEndPoint robot = new IPEndPoint(IPAddress.Parse("192.168.0.1"), 10000); // Die Adresse des Roboters
UdpClient client = new UdpClient();
client.Connect(robot);
// Senden
client.Send(cmd, cmd.Length)
// Empfangen
if (client.Client.Poll(someTime, SelectMode.SelectRead))
{
byte[] buffer = client.Receive(ref dummy);
Alles anzeigen
Danke Urmel. Also, ich habe nun versucht mein Programm auf ein paar Zeilen runterzudestillieren:
byte[] sData = new byte[196];
UdpClient udpRobot = new UdpClient();
IPEndPoint adrRobot = new IPEndPoint(IPAddress.Parse("192.168.0.1"),10000);
udpRobot.Connect(adrRobot);
IPEndPoint dummy = new IPEndPoint(IPAddress.Any, 0);
//start connection
sData[0] = 0;
udpRobot.Send(sData, sData.Length);
if (udpRobot.Client.Poll(1000000,SelectMode.SelectRead))
{
byte[] rData = udpRobot.Receive(ref dummy);
}
// close connection
data[0] = 255;
udpRobot.Send(sData, sData.Length);
if (udpRobot.Client.Poll(1000000, SelectMode.SelectRead))
{
byte[] rData = udpRobot.Receive(ref dummy);
}
Alles anzeigen
Und der Rest bleibt. Robot antwortet nicht, kein Fehler und Progamm-Monitor (auch ueber TCPIP) zeigt dass er auf der MXT Zeile bleibt. Ich bin echt ratlos
Hallo,
ich bin da ehrlich gesagt auch etwas ratlos, ich mache das seit über 10 Jahren und schon mit knapp 200 Robotern.
Da ist nichts kompliziertes.
Das Problem bei UDP-Kommunikation ist nur, dass es so gut wie keine Fehlermeldungen über die Zustellung gibt. Wenn ein Paket ins Nirwana gesendet wird, führt das bei keinem der Partner zu irgendwelchen Meldungen außer einem Timeout auf der Leseseite.
Da der Roboter bei TCP geantwortet hat, gehe ich mal davon aus, das die Hardware ok ist. Auf ein Ping antwortet er ja auch ?
Dann bleiben noch die IP-Adressen. Die im C# Programm ist wirklich die des Roboters und die im Roboterprogramm die des PCs ?
Stimmen die Parameter des Mxt-Befehls ?
Außerdem könnten noch allerlei Parameter verstellt sein. Im Normalfall braucht man, wenn die IP-Adressen so bleiben sollen, für ein so einfaches Echtzeitprogramm bei einen Roboter im Auslieferzustand keinen einzigen Parameter verändern. Auch das C++ Beispiel aus dem Handbuch funktioniert bei einem frisch ausgepackten Roboter ohne Probleme. Wenn es das nicht tut, ist das schon ein Zeichen, dass jemand irgendwas verstellt hat.
Von denen die du erwähnt hast, haben nur wenige mit der Echtzeitsteuerung zu tun, es kann höchstens sein, dass sie irgendwelche Seiteneffekte haben, die die UDP-Übertragung verhindern.
Stehen IP-Adresse, Maske und Gateway beim Roboter auf sinnvollen Werten ? (Gateway wird nicht gebraucht), NETIP usw.
NETHSTIP, NETMODE und Konsorten fasst man nur an, wenn der Roboter einen externen TCP-Server konnekten soll. Sonst sollte das immer auf den Ausliefereinstellungen bleiben.
Deine Beschreibung von NETPORT war oben falsch, der Parameter hat 10 Einträge, den ersten fürs UDP, die anderen für die TCP-Verbindungen OPT11 bis OPT19.
Die meisten Parameter zur Echtzeitsteuerung dienen der Kompatibilität mit der alten Arcnet-Echtzeitsteuerung und der alten Movemaster Command Sprache. Man sollte sie in der Regel nicht anfassen.
Das einzige was mir sonst noch auffällt, ist der Aufbau der Echtzeitdatenstruktur in dem Code aus der PM. Ich mache das etwas anders, ohne irgendwelche Arrays und eigene Annahmen darüber, wie groß etwas ist. Man kann die ganze Struktur aufbauen wie in C. Jeweils mit StructLayout Attributen, auch den union kann man so nachbauen. Nirgendwo explizit size angeben. Danach das ganze große Ding mit Marshal kopieren. Ich würde aber erwarten, das der Roboter piepst, wenn er irgendwelchen Unsinn gesendet kriegt.
Mehr kann ich da auch nicht zu sagen. Ich halte das ganze aber eher für ein Problem kruder Netzwerkeinstellungen, als für ein Programmierproblem. Im Gegensatz zu manchen TCP-Sachen funktioniert die reine Echtzeitsteuerung sonst "out of the box".
Grüße
Urmel
Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können