Echtzeitsteuerung

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;
}

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,

Zitat von MistaBishi

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 MistaBishi

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.

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.

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

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();

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();

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);

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);
            }

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