Hallo Ich habe eine etwas unkonventionelle Idee für ein IP-over-RS485-System. Die Architektur besteht aus einer "Master"-Einheit (z.B. ESP32 mit WiFi) und mehreren "Slave"-Einheiten (z.B. WCH CH32V*). Der herkömmliche Ansatz wäre wahrscheinlich, dass die "Slave"-Einheiten die Daten an die "Master"-Einheit senden, welche sie dann sammelt und ins Internet überträgt. Dieser Ansatz erfordert jedoch eine enge Abstimmung zwischen "Master" und "Slave", da sie die übertragenen Werte voneinander kennen müssen. Daher spiele ich mit der Idee, auf den "Slave"-Einheiten ebenfalls einen IP-Stack laufen zu lassen, während der "Master" als Router fungiert. Das bedeutet, dass der "Slave" hinter einem NAT einen regulären Internetzugriff hat. Ist ein solches Vorhaben bei geringem IP-Datenaufkommen (z.B. MQTT) überhaupt sinnvoll? Oder stosse ich bereits an die Grenzen von RS485? Mir ist bewusst, dass ich dafür eine Form von Kollisionserkennung/-vermeidung benötige. Welche Protokolle eignen sich hier? Gibt es geeignete Protokolle, in die ich meine IP-Pakete einpacken kann? Ich freue mich auf eure Meinungen und Erfahrungen zu diesem Thema!
Egal was Du da auch machst, für Dein Vorhaben gibt es keine Standardlösung. Für RS232 hättest Du PPP machen können, aber das setzt eben eine Punkt-zu-Punkt Verbindung voraus. Wenn Du schon soweit bist, einen kompletten IP-Stack auszurollen, der ja ohnehin schon recht fett für einen uC ist, dann ist der Weg zu Ethernet selber nicht mehr so weit. Das ist dann wieder eine Standardlösung. Wenn Du gerne eine Zweidraht-Verkabelung ohne Trafo und mit kleinen Steckern hättest, dann gibt es Single Pair Ethernet SPE, in Deinem Fall 10BaseT1S. Microchip hat dafür sowohl nackte PHYs für RMII als auch MAC+PHY für SPI. Da sind dann all Deine Probleme, die Du mit RS485 hast, bereits gelöst, und zur Anbindung an einen Router mit normalem Ethernet reicht ein Switch bestehend aus LAN9354 (RMII+2*RJ45) plus LAN8671 SPE PHY. https://www.microchip.com/en-us/product/LAN8651 https://www.microchip.com/en-us/product/LAN8671 SPE hat wie normales Ethernet bereits automatisch galvanische Trennung (hier kapazitiv) eingebaut und ist gleichspannungsfrei. Du musst also keinen GND mitschleppen und hast keine Common Mode Probleme etc. Wenn Du auf RS485 bleiben willst, würde ich auf IP verzichten. Modbus/RTU ergibt auf den Slaves ein sehr sehr sehr viel schlankeres System und kann einfach auf Modbus/TCP über Ethernet/Wifi auf dem Master umgesetzt werden. Damit sind die Slaves übers Internet einzeln abfragbar, ohne dass der Master jeden einzelnen Parameter in einer Liste haben müsste. Und das funktioniert seit 40 Jahren. fchk
:
Bearbeitet durch User
Frank K. schrieb: > 10BaseT1S 8 Busteilnehmer, 25m. Ist die Frage ob dem TO das reicht. > Wenn Du auf RS485 bleiben willst, würde ich auf IP verzichten. +1
Frank K. schrieb: > Wenn > Du gerne eine Zweidraht-Verkabelung ohne Trafo und mit kleinen Steckern > hättest, dann gibt es Single Pair Ethernet SPE, in Deinem Fall > 10BaseT1S. Microchip hat dafür sowohl nackte PHYs für RMII als auch > MAC+PHY für SPI. Stimmt, zu Single Pair Ethernet hatte ich mal einen Vertreter da. Das ist ein sehr guter Vorschlag! Zu dem Zeitpunkt war jedoch die Einschränkung, dass der Multipoint betrieb noch nicht möglich ist. Hat sich da etwas geändert? In den Datenblättern lese ich an mehreren Stellen, dass Multipoint möglich sein soll. Ein Schaubild o.ä. habe ich jedoch nicht gefunden. Frank K. schrieb: > Wenn Du auf RS485 bleiben willst, würde ich auf IP verzichten. Danke für deine Einschätzung!
>unkonventionelle Idee für ein IP/Ethernet-over-RS485-System RS485: halbduplex über 2 Adern ~ 1Mbit Ethernet: minimal Halbduplex über 2 Adern ~ 10Mbit (Twisted Pair statt Coax) die Endpunkte sind leistungsfähig genug (Protokollaufwand, nicht Datendurchsatz) um einen IP-Stack zu verwalten. Der Datensammler hat genug Leistung um die Datenverbindungen der Endpunkte zu verwalten. Alle Geräte haben direkten Internetzugriff. Ist die Motivation für RS485 der geringere Hardwarepreis statt eines echten Ethernet Controllers wie z.B. Microchip ENC28J60 ? Was für uC willst du für die Endpunkte verwenden ? Ist SPI statt UART möglich (Datendurchsatz!)? Kann die Kosteneinsparung auf der Hardware die erhöhten Softwareaufwände aufwiegen ? Wann muss es fertig werden ? Oder ist das ein Projekt "weil es einfach geht" ? > Wenn Du auf RS485 bleiben willst, würde ich auf IP verzichten. dito >Egal was Du da auch machst, für Dein Vorhaben gibt es keine Standardlösung. dito, weil diese Lösung keinerlei Vorteile bietet Beim Preis für einen Ethernet Controller+uC kann man aber auch einfach alle Endpunkte mit einem ESP32 Modul ausstatten. Keine Kabel, nur einen WLAN Access Point, IP im ESP32 mitgeliefert.
Tom schrieb: > Stimmt, zu Single Pair Ethernet hatte ich mal einen Vertreter da. Das > ist ein sehr guter Vorschlag! > > Zu dem Zeitpunkt war jedoch die Einschränkung, dass der Multipoint > betrieb noch nicht möglich ist. Hat sich da etwas geändert? In den > Datenblättern lese ich an mehreren Stellen, dass Multipoint möglich sein > soll. Ein Schaubild o.ä. habe ich jedoch nicht gefunden. SPE ist nicht ein einziger Standard, sondern mehrere (>5). 1000BASE-T1, 100BASE-T1 und 10BASE-T1L sind physikalisch Punkt-zu-Punkt Verbindungen, die einen Switch benötigen. 10Base-T1S und zukünftig 10Base-T1M sind Busse (Multidrop). Die einzelnen Standards sind untereinander NICHT kompatibel. Du willst 10Base-T1S (IEEE802.3cg-2019). https://cdn.vector.com/cms/content/events/2021/vAES21/vAES21_02_Miller_Microchip.pdf https://de.teledynelecroy.com/doc/10base-t1s-auto-ethernet-tech-brief https://www.analog.com/en/thought-leadership/why-10base-t1s-is-the-missing-ethernet-link.html fchk
Du kannst versuchen dir vlt. eine Ethernet zu RS485 bridge zu machen. Du kannst ja die TX/RX Mac-Frames die vom/zum Eth-Mac kommen ja einfach RAW darüber durchsenden. Musst dir dann ein bisschen überlegen ob du noch ein bisschen Protokoll / Kolission-Detection selber implementierst. Je nach Datenverkehr dürfte der Packet-Loss dann aber sehr hoch ausfallen. TCP/IP sollte aber gegen packet-loss theoretisch immun sein.
Auf RS485 will man eigentlich keine Kollisionen haben. Das heißt nämlich, dass auf physikalischer Ebene zwei Push-Pull-Treiber gegeneinander arbeiten, und wer dabei gewinnt, ist nicht definiert. Das ist außerdem nicht gut für die Ausgangstreiber. Bei CAN ist das anders. Da haben die Transceiver keine Push-Pull-Treiber, sondern Open-Drain, und Kollisionen sind dort definiert und werden schon auf Hardwareebene erkannt und behandelt. Wenn IP über RS485, dann per Token Passing Mechanismus, um eben Kollisionen zu vermeiden. Ethernet-Header über RS485 zu senden ist grob ineffizient und unnötig. Wenn, dann direkt IP via CSLIP mit Headerkompression. Siehe RFC1144. Aber eigentlich ist auch das ineffizient - Modbus wäre hier tatsächlich passender. fchk
Tom schrieb: > Welche Protokolle eignen sich hier? Frank K. schrieb: > Egal was Du da auch machst, für Dein Vorhaben gibt es keine > Standardlösung. Ich widerspreche teilweise: Denn ich hatte mal ein GSM Modem, dass IP über den seriellen Port fuhr. Das Verfahren ist standardisiert und wird nach meinem Kenntnisstand immer noch von allen gängigen Desktop Betriebssystemen unterstützt: https://de.wikipedia.org/wiki/Serial_Line_Internet_Protocol Da steht auch etwas zur Datenrate. Das war allerdings nicht für einen Bus mit mehr als 2 Teilnehmern gedacht. Du bräuchtest zusätzlich noch etwas gegen Kollisionen. Die Frage ist, ob der Aufwand dazu gerechtfertigt ist. IP ist ja an sich schon relativ schwergewichtig.
:
Bearbeitet durch User
Steve van de Grens schrieb: > https://de.wikipedia.org/wiki/Serial_Line_Internet_Protocol > > Da steht auch etwas zur Datenrate. > > Das war allerdings nicht für einen Bus mit mehr als 2 Teilnehmern > gedacht. Ganz genau. Und genau das ist ein Riesenproblem. P2P ist Pipifax. Jeder, der schon in den frühen 90ern oder noch früher im Internet war, hat natürlich entsprechende Protokolle und Geräte genutzt.
Steve van de Grens schrieb: > Ich widerspreche teilweise: > > Denn ich hatte mal ein GSM Modem, dass IP über den seriellen Port fuhr. > Das Verfahren ist standardisiert und wird nach meinem Kenntnisstand > immer noch von allen gängigen Desktop Betriebssystemen unterstützt: > > https://de.wikipedia.org/wiki/Serial_Line_Internet_Protocol Dein GSM-Moden wird mit Sicherheit PPP gesprochen haben und nicht (C)SLIP. Als (C)SLIP aktuell war, war noch das C-Netz Stand der Technik. Oder AMPS in den USA. > Das war allerdings nicht für einen Bus mit mehr als 2 Teilnehmern > gedacht. (C)SLIP und PPP sind überhaupt gar nicht für Busse gedacht und geeignet, nur für Punkt-zu-Punkt Verbindungen. > Du bräuchtest zusätzlich noch etwas gegen Kollisionen. ... die Du eben bei RS485 nicht willst. Und weder bei SLIP noch bei PPP gibt es irgendwo im Standard die Möglichkeit, mehrere Geräte zu adressieren. Kann man irgendwie machen, aber nicht mit SLIP und PPP. Also: 6. Setzen. fchk
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.