Hallo zusammen Ich habe die Idee, dass ich in einer Applikation mehrere Sensoren und Aktoren örtlich verteile und in einem Gigabit Ethernet-Netzwerk verbinde. Auf dem Netzwerk sollen insgesamt sicherlich vier Anwendungen parallel laufen: a) PTP um alle Knoten zu synchronisieren. Diese Protokoll setzt auf sehr kurze Paktete (64Byte) und hat meiner Meinung nach auch keine Probleme mit Latenzzeit. b) Messdaten von allen Sensoren, diese hätte ich gerne mit UDP oder ähnlichem und einer Forward Error Correction geschickt. Da ich mir den zusätzlichen Aufwand von TCP eigentlich ersparen möchte. c) Aktordaten, dies hätte ich vermutlich mit dem RTP gemacht...Auf dieser Schiene habe ich jedoch noch überhaupt keine Erfahrung. Ich möchte einfach gerne auf einen verbreiteten Standard setzen, welcher dann von meinen Switches etc. auch erkannt wird. Bei der Regelung wäre mir eine Zykluszeit von so 50us lieb... d) Firmware Update, hier bietet sich natürlich TCP an. Doch wenn ich schon die Messdatenerfassung mit UDP hinkriege wäre mir hier eine UDP Lösung sympatisch. Das alles soll schlussendlich auf einem Cyclone V oder ähnlich laufen. Daher möchte ich nicht unnötige Ressourcen verbrauchen. Hat jemand mit solchen Anwendungen schon Erfahrung und kann meine Ideen bestätigen oder wiederlegen? Mir ist natürlich klar, dass ich grundsätzlich mit möglichst kleinen Paketen arbeiten muss. Weiter wird das Firmwareupdate definitiv nicht gleichzeitig mit der Regelung betrieben. Gruss
Die einzige etablirete Lösung für Echtzeitfähigkeit nennt sich EtherCAT. Damit sind Zykluszeiten wie 50us mit harter Echtzeit machbar.
>Bei der Regelung wäre mir eine Zykluszeit von so 50us lieb
Soll das ein Witz sein ? Was spricht gegen eine lokale Regelung ? Eine
lokale Regelung wird auch guenstiger sein.
Siebzehn Für Fuenfzehn schrieb: >>Bei der Regelung wäre mir eine Zykluszeit von so 50us lieb > > Soll das ein Witz sein ? Was spricht gegen eine lokale Regelung ? Eine > lokale Regelung wird auch guenstiger sein. Und wenn zwischen Sensor und Aktor 50m Kabel liegen? Du hast doch keine Ahnung von der Anwendung. Es interessiert ihn auch nicht was du dazu denkst. Er interessiert sich für echtzeitfähiges Ethernet. Er sucht sicher keine Diskussion über seine systemische Struktur der Regelung. Sonst würde er das schreiben !
Das Problem ist wie gesagt, dass ich die Sensoren und Aktoren gerne örtlich getrennt haben möchte und über eine standardisierte Verbindung verbinden würde. Während der Regelung wird ziemlich sicher nicht sehr viele Datenverkehr sein. Und bei kleinen Paketen in einem Gigabit Ethernet sehe ich eine Möglichkeit von so kleinen Zykluszeiten. EtherCAT muss ich mir wohl mal genau anschauen... Aber vielleich ist so ein Switch au eine interessante Lösung: https://www.tttech.com/products/aerospace/flight-rugged-hardware/switches/tte-switch-a664-a600-pro/ Weil man da immerhin schon Prioritäten etc verteilen kann
Sensoren uns Aktoren zu trennen macht sicherlich sinn wenn der Prozess raeumlich so ausgedehnt ist. Ethernet als Verbindung zum Controller ist sicherlich auch ok, sofern man nicht beiden Enden nochmals je ein Betriebssystem benoetigt. Muss man ja nicht zwingend. Die meisten Leute verwenden allerding Ethernet in Verbindung mit einem Betriebssysyem, und setzen nicht Lowlevel drauf auf. Per Lowlevel sind 25 KSample einfach. Mit einem Betriebssystem definitiv nicht.
Reines Ethernet ist vom Zeitverhalten nicht deterministisch. Für eine Regelung willst Du aber ein deterministisches Zeitverhalten haben. Dafür gibt es zum einen spezielle Feldbusse wie ProfiBus, AS-Bus, LON, CAN und noch viele andere, und es gibt Feldbusse, die zwar Ethernet als Basismedium verwenden, aber durch diverse Erweiterungen ein deterministisches Zeitverhalten erzeugen, zB das erwähnte EtherCAT, aber auch Ethernet/IP, ProfiNet und einige andere. Einige dieser Ethernet-Varianten funktionieren mit herkömmlichen Switches, andere brauchen spezielle Switches. CAN ist sicher hardwaretechnisch die preiswerteste Lösung, da Du entsprechende Controller und Transceiver in großer Zahl an jeder Ecke bekommst. Automotive und die damit verbundenen riesigen Stückzahlen machen das ganze sehr preiswert. Einen einfachen CAN-Knoten kannst Du für wenige € bauen, ein ProfiBus-Knoten wird sicher eine Zehnerpotenz teurer sein. fchk
Frank K. schrieb: > CAN ist sicher hardwaretechnisch die preiswerteste Lösung Kommt nur leider um Größenordnungen nicht an 50us dran...
Mir ist klar, dass Ethernet grundsätzlich nicht deterministisch ist. Jedoch denke ich mit geeigneter Priorisierung und kleinen Paketen eine gute Lösung erreichen kann. Gigabit hilft dann natürlich enorm! Mir ist weiter noch eine genaue Zeitsynchronisation sehr wichtig. Daher denke ich, dass ich mich auf Ethernet und das PTP setzen muss. Alle anderen Feldbusse scheinen mir keine Möglichkeiten aufzuzeigen, um mein System sauber auf eine einheitliche Uhr zu synchronisieren uns so die Messungen gleichzeitig zu Starten/Stoppen. Hier spreche ich von einigen ns... EtherCAP etc bauen halt alle noch auf das 100MBit Ethernet, welches ich grundsätzlich nicht unbedingd nutzen möchte. Sehe ich dies grundsätzlich korrekt, dass ich die QoS also die Priorität von Paketen steuern kann? Ist dies auch bei einfachen UDP-Paketen möglich? Oder muss ich für so was ein RTP Protokoll einsetzen?
Daniel T. schrieb: > Sehe ich dies grundsätzlich korrekt, dass ich die QoS also die Priorität > von Paketen steuern kann? Was dir nichts nützt, wenn dein Zielport gerade von einem Gigabit-Jumbopaket einer anderen Anwendung belegt ist. MfG Klaus
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.