Hallo, in meiner Abschlussarbeit soll ich ein Real Time Verbindung von einer Controller-Einheit zu einem Roboter aufbauen. Beidseitig wird ein Cortex M§ eingesetzt. Nach meinen Recherchen taugen reines TCP oder UDP nicht für RT. Bleiben noch Protokolle wie zum Beispiel Profinet. Gibt es Alternativen? Open Source Alternativen? Ich bin neu in der Thematik. Wie gehe ich am besten vor? Danke Spinter
Spinter schrieb: > Nach meinen Recherchen taugen reines TCP oder UDP nicht für RT warum sollte UDP nicht für RT geeignet sein? Oder hast du bedenken weil im Ethernet selber zu "Staus" wegen Kollisionen kommen kann?
Ich würde einfach reine Ethernet-Frames senden und empfangen. Das Protokoll oben drauf machst du selbst. Damit hast du eine gute Kontrolle über die Timings. Ob du wirklich ein bereits existierendes Protokoll (wie Profinet) oben drauf brauchst musst du selber wissen. Aber überlege vorher, wozu. gruß cyblord
Ob etwas in "real time" geht oder nicht, hängt ja wohl von den Erfordernissen ab. Wenn die Anforderungen an Latenz, Jitter und Bandbreite i.O. sind, geht Ethernet (UDP) definitiv.
UDP würde schon gehen, aber wenn er nur eine Verbindung vom Controller zu einem Roboter haben will, wozu dann noch IP und UDP mitschleppen? Oder muss das ganze tatsächlich über das Internet funktionieren? Oder mindestens zwischen LANs welche durch Router getrennt sind?
:
Bearbeitet durch User
Hallo Spinter, wie wäre es denn mit EtherCAT von Beckhoff. Ist mir vor einiger Zeit über den Weg gelaufen und macht einen brauchbaren Eindruck. http://www.beckhoff.de/default.asp?ethercat/default.htm MfG Sven
Fuer eine Selbstbau punkt zu punkt verbindung kann man den Stack wegschmeissen und auf der tiefsten Stufe aufsetzen. Dann wird's auch deterministisch und schnell.
nochwas schrieb: > Fuer eine Selbstbau punkt zu punkt verbindung kann man den Stack > wegschmeissen Mit reinem Ethernet geht natürlich trotzdem Multipoint im selben LAN. Wenn man auf MAC aufsetzt und alles über die Mac-Adresse anspricht. gruß cyblord
SvenW schrieb: > wie wäre es denn mit EtherCAT von Beckhoff. Ist mir vor einiger Zeit > über den Weg gelaufen und macht einen brauchbaren Eindruck. Benutzen wir auch in unseren Produkten. Echtzeitiger gehts nicht mehr ;-) (und schnell ist es auch)
:
Bearbeitet durch User
Kommt auf den Roboter an. Selbstgebaut oder ein Industriedingens? Ethercat läßt sich schön redundant konfigurieren mit "Reserve-Kommunikationsweg". Ist die Wahl bei kritischen Anforderungen. Safety über Ethercat geht auch, hab ich aber noch nit programmiert. Profinet ist ähnlich schnell und es gibt haufenweise Controller, die sich auf ein Projekt draufsetzen lassen. Die übernehmen die Konfiguration über ein HTML interface, und du brauchst dich nur noch um den bereitgestellten Datensatz kümmern. Ich hatte schon Anlagen, da haben 4 gleiche OEM-Interfacekarten in 4 vollkommen verschiedenen Geräten verschiedener Hersteller miteinander geredet. Profisafe ist mittlerweile Standard. Beide Protokolle brauchen managed switches für die "Echtzeitfähigkeit". Wenns jetzt nur darum geht, über WLAN irgendwas spatierenfahren zu lassen, kümmer dich nicht um diesen Protokoll-overhead. UDP reicht.
wenn beide Seiten ein uIP oder lwIP auf dem Cortex-Mx laufen haben dann sind Reaktionszeiten <=1ms locker drin, für die Übermittlung von Steuerbefehlen und Rückmeldungen sollte das reichen. Stören könnten viele Broadcasts, aber dazu muss man das Netz klein und sauber halten. UDP wäre dabei noch etwas schlanker als TCP wenn man mit kleinen Datenpaketen hinkommt. Bei TCP sollte noch das 'Nagling' abgeschaltet werden wenn vorhanden, ist bei den genannten Stacks aber kein Problem.
EtherCAT ist eine mächtig umfangreiche Spec, die wirst du auf einem Cortex-M nicht machen wollen und ist mir auch noch nicht untergekommen. Das braucht zB auch zwei Ethernet Phys, dazu gibt es spezielle ASICs, FPGAs oder spezielle Prozessoren wie die ti Sitara Serie, Cortex-A mit Linux drauf.
Ich schmeiss jetzt einfach kurz in die Runde was unser Lehrer bei RT immer sagte: Was ist in diesem speziellen Fall RT? RT ist nicht definiert, es kommt auf die Umgebung an. Wenn Dein Roboter gegebenenfalls nur 1 Pos pro Stunde anfahren könnte, wären 20ms z.B. ziemlich RT. Wenn er aber für eine Pos 20ms benötigt sind 20ms sicher nicht mehr RT. Denke Du solltest Dich zuerst einmal damit befassen was in Deinem Fall als RT zu bezeichnen ist. Es Grüessli
Übersicht Feldbusse: Modbus TCP: Ist wahrscheinlich der simpelste Ethernet basierte Feldbus. Aber dafür ned Echtzeitfähig in der Literatur steht 50ms Sekunden herum. Hab ich schon mit unter 10ms Zykluszeit auch betrieben. Profinet: Geiles Protokoll is hald von Siemens. Es hat einen relativ großen Memory Footprint. Zykluszeit um die 10ms bei RT und bei IRT gehts runter bis 250µs (31,25µs). Es ist relativ Komplex. Ethernet/IP: Naja Amerikanisch hald ist relativ komplex vom Objektverzeichnis her. Für so 10ms herum Zykluszeit ausgelegt. Mit CIP Motion und Zeitsynchronisation geht auch weniger. Ethercat (Katzenbus): Ok dazu brauchst du wie schon gesagt ein FPGA oder ASIC (gibt Slave ASIC von Beckhof) Lizenzmodell is ech blöd. Aber es ist schnell und hat eine Allergie gegen Switche und Hubs. (Schieberegister) Powerlink: Ist Open Source. Gibt für einige Plattformen fertige Portierungen. Als Beispiel die Linux variante. Mit einem normalen µC sind da auch so 1ms herum möglich. Mit FPGA Lösung so ca. 200ns. Die EPSG ist normalerweise sehr Hilfsbereit. Hab da relativ gute Erfahrungen gemacht. Interessante Dinge sind auch für Realtime: Renesas TPS-1 für Profinet Innovasic Fido5000 REM interessanter Netzwerk Chip/Switch kann alle Realtime Ethernet Protokolle Hilscher netX als Netzwerkcontroller Du kannst auch was eigenes basteln und dabei über viele blöde Sachen stolpern.
patsch007 schrieb: > Hilscher netX als Netzwerkcontroller Bei dem Namen klingelt es irgendwie bei mir.
Markus Wagner schrieb: >> Hilscher netX als Netzwerkcontroller > Bei dem Namen klingelt es irgendwie bei mir. In wie fern den ? Hab die schon öfter bei einigen SPS Herstellern verbaut gesehen.
Spinter schrieb: > Nach meinen Recherchen taugen reines TCP oder UDP nicht für RT. Was ist RT? Das ist keine Ja/Nein-Spezifikation. Du mußt schon Zeitvorstellungen nennen.
cyblord ---- schrieb: > UDP würde schon gehen, aber wenn er nur eine Verbindung vom Controller > zu einem Roboter haben will, wozu dann noch IP und UDP mitschleppen? IP braucht man ja nicht. Ein simples UDP ist ja ausreichend für die Kommunikation. Gemacht wird es von den Kunden meistens deshalb, weil sie Leitungen sparen müssen. Gerade bei Robotern hat man in den Armen und Gelenkübergängen meistens sehr wenig Platz. Ethernet hat den Vorteil, dass es über eine geringe Zahl von Verbindungsdrähten viel Bandbreite rüberbekommt und die Chips sowie vor allem die Kabel absolute Massenware sind.
Jürgen Schuhmacher schrieb: > IP braucht man ja nicht. Ein simples UDP ist ja ausreichend für die > Kommunikation. UDP braucht aber IP! Man kann auch nur reine Eathernet-Pakete verschicken. Aber zurück zum Thema: wie bereits erwähnt, ohne Randbedingungen kann man nur abschätzen, was mit RT gemeint ist.
Und was ist die Aufgabe? Baust du den Roboter und die Steuerung muss halt irgendwie funktionieren? Oder wird das eine theoretische Abhandlung über das optimale Netzwerkprotokoll?
>Gibt es Alternativen?
Es gibt 1000e Alternativen, und man nicht kein umständliches Protokoll,
wenn man's nicht braucht.
Jürgen Schuhmacher schrieb: > IP braucht man ja nicht. Ein simples UDP ist ja ausreichend [] Du hast das Schichtenmodell verstanden
patsch007 schrieb: > Markus Wagner schrieb: >>> Hilscher netX als Netzwerkcontroller >> Bei dem Namen klingelt es irgendwie bei mir. > > In wie fern den ? Ich hatte mich mit dem Namen irgendwie vertan. Gemeint war sich er das hier: http://de.hilscher.com/home_aboutus.html
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.