Hallo, Ich bin noch sehr neu in der Materie, falls es Dokus oder Wikis gibt die ich zu meiner Frage noch nicht gefunden habt könnt ihr mich gerne erleuchten. Hat hier jemand Erfahrungen mit sehr weiter Signalübertragung mittels CAN Bus FD? Ich müsste über eine Strecke von ca. 11 km Daten von ca. 500 Knoten abfragen oder Befehle versenden. Übertragen wird alles mittel twisted pair Kabel. Mein Lösungsansatz wäre: Alle 1000 Meter ein CAN-FD Gateway für eine Bandbreite von bis zu 50kbit/s => maximal 46 Knoten pro Segment. Die Knoten melden Ereignisbasiert und nicht zu oft. Würde das so funktionieren?
Das FD kannst du dir im Grunde sparen, die Datenraten schaffst du auf die Längen sowieso nicht. Oder sind die Nodes in max. 10m Entfernung zum Gateway? Die Gateway Idee ist OK, wenn die Nodes nahe sind. Zwischen den Gateways würde ich Ethernet oder sowas in der Art einsetzen. Mal einige Gegenfragen: Was soll das werden? Wieso versucht jemand der sich selbst als Neuling einordnet, ein CAN Universum mit 500 Teilnehmern zu erschaffen? Wie viel Geld hast du zur Verfügung? Jeder Node kostet dich mindestens 2€-3€, je nachdem was er noch machen soll. Wie viele Vector Lizenzen + Cases sind schon im Bestand?
Ich soll prüfen, ob es Grundsätzlich machbar wäre. Es müsste jedoch leider über ein Zweidraht System laufen. Sonst könnte darüber ja EtherCAT verwenden. Der Aufbau wäre so: Master == Node1 == NodeN == Gateway == NodeN == Gateway ... Die Technik wäre schon vorhanden und die zusätzlichen Nodekosten wären vertretbar. Es soll lediglich geprüft werden, ob CAN Bus eine alternative zu RS 485 wäre. Alternativ hätte ich sonst EtherCAT in Betracht gezogen. Die Entfernung zwischen den Nodes ist in der Regel < 60 Meter.
Längenangaben je nach Bitrate sind zB hier aufgelistet: https://infosys.beckhoff.com/index.php?content=../content/1031/cx805x_hw/2037601547.html Insofern würde das schon gehen. Zum Thema: CANFD versus CAN classic: CANFD kann auch mit fixer Baudrate betrieben werden, was zwar unsinnig klingt (FD=flexible datarate), aber trotzdem noch den Vorteil bietet, längere Nachrichten als 8 Byte zu verschicken. Kann manchmal Protokoll-Overhead sparen, wenn's drauf ankommt. Ansonsten ja, classic-CAN reicht oft völlig. Und noch 'was: Ich hab schon geschmolzene Sockel von CAN-Transceivern gesehen, weil offenbar in der Nähe ein Blitz eingeschlagen hatte. Es macht bei solch großen Ausdehnungen Sinn, galvanisch getrennte Transceiver vorzusehen. Auch die sterben bei einigen kV, aber zumindest die "kleinen Ereignisse" überleben sie besser als klassische Transceiver.
CAN ist eigentlich denkbar ungeeignet für längere Strecken, da quasi alle gleichzeitig senden können (es ein dominantes und ein Rezessives Signal gibt) und der Sender gleichzeitig auf alle hören muss. Für längere Strecken ist Punkt-zu-Punkt/Daisy-Chain das Mittel der Wahl, wenn Latenzen nicht allzu kritisch sind. Erleichtert die Fehlersuche ungemein. Ansonsten irgendwas mit jederzeit nur ein Sender.
Hi, danke für die Info die Auflistung hatte ich mir auch schon mal angesehen. Wo ich die meisten Fragezeichen habe liegt in der Verwendung der Gateways. Ich bin mir nicht sicher ob es da irgendwelche "Probleme" gibt die nicht er lesbar sind. Zum Beispiel Kollisionen oder ähnliches, aber dafür sind die Gateways ja eigentlich da, dass nicht wie bei Repeatern Probleme auf der Leitung entstehen. Ich hätte dann ja 11 Segmente, dass die Bandbreite höher ist, als bei der Verwendung von Repeatern. Dazu habe ich keine Informationen gefunden, ob verkettete Segmente irgendwo ein Limit bergen.
Bruno V. schrieb: > CAN ist eigentlich denkbar ungeeignet für längere Strecken, da quasi > alle gleichzeitig senden können (es ein dominantes und ein Rezessives > Signal gibt) und der Sender gleichzeitig auf alle hören muss. > > Für längere Strecken ist Punkt-zu-Punkt/Daisy-Chain das Mittel der Wahl, > wenn Latenzen nicht allzu kritisch sind. Erleichtert die Fehlersuche > ungemein. Ansonsten irgendwas mit jederzeit nur ein Sender. Also wäre da die Richtung in EtherCat eher der Weg? der Nachteil wäre nur, dass ich dann mindestens eine "Kreis" bräuchte, dass nach dem Ausfall eines Knoten nicht alle dahinter liegenden ausfallen? Aktuell ist ein Kabel mit Stichen verlegt für jeden Knoten.
Lucas schrieb: > Also wäre da die Richtung in EtherCat eher der Weg? Einer von vielen. > der Nachteil wäre nur, dass ich dann mindestens eine "Kreis" bräuchte, > dass nach dem Ausfall eines Knoten nicht alle dahinter liegenden ausfallen? Immerhin siehst Du dann, wo der Fehler ist. Bei einem Bus ist eine Lokalisierung deutlich schwieriger. Aber ja, wenn beliebig viele Teilnehmer ausfallen können, ist P2P schwierig. Es ist aber möglich, die Kommunikation durchzuschleifen, wenn das Node z.B. in SW ausfällt Aktuell > ist ein Kabel mit Stichen verlegt für jeden Knoten. Dann bleibt nur ein Bus. Da wäre dann die Frage, warum die von RS485 weg willst. Wegen gleichzeitig Senden?
Bruno V. schrieb: > Dann bleibt nur ein Bus. Da wäre dann die Frage, warum die von RS485 weg > willst. Wegen gleichzeitig Senden? Der verwendete Chip wurde eingestellt und da war die Überlegung mal alles in Frage zu stellen, daher die Idee. Gleichzeitiges senden wäre egal. Es ging primär um Alternativlösungen, die im Idealfall eine höhere Bandbreite bieten.
Lucas schrieb: >> Dann bleibt nur ein Bus. Da wäre dann die Frage, warum die von RS485 weg >> willst. Wegen gleichzeitig Senden? > > Der verwendete Chip wurde eingestellt Welcher denn? RS485 Tranceiver gibt es wie Sand am Meer,
Lucas schrieb: > Es ging primär um Alternativlösungen, die im Idealfall eine höhere > Bandbreite bieten. Wobei 485, Ethercat und CAN recht unterschiedlich sind. Was sind denn ungefähr Deine Anforderungen? Reden wir von 100 Byte pro Sekunde oder 100Bit mit wenigen ms Latenz? Wie lang sind die Stichleitungen etwa? Ethercat braucht ja auch einen geschlossenen Ring (egal ob Virtuell oder echt). Und wie läuft die Fehlersuche? Ein Kurzschluss/Kabelbruch irgendwo im Kabel kann ja praktisch nur noch mit Signallauf-Testern (Abstand bis zur Störstelle) gefunden werden. Oder werden dann Verbindungen per Hand/Relais geöffnet und geschlossen? Geht es um eine Eigenentwicklung oder sollen da COTS-Geräte aus dem Katalog verbunden werden?
Grundsätzlich um Eigenentwicklung. Zu den Stichleitungen kann ich nichts genaues sagen ich vermute 50cm bis 1m. Latenzen und Datenrate wären eher zweitrangig. Datenrate wären alles ab 25 kbit/s mehr als ausreichend.
Falk B. schrieb: > Lucas schrieb: >>> Dann bleibt nur ein Bus. Da wäre dann die Frage, warum die von RS485 weg >>> willst. Wegen gleichzeitig Senden? >> >> Der verwendete Chip wurde eingestellt > > Welcher denn? RS485 Tranceiver gibt es wie Sand am Meer, Das war ein 32-bit Microkontroller, den es jetzt nicht mehr gibt.
Lucas schrieb: > Dazu habe ich keine Informationen gefunden, ob verkettete > Segmente irgendwo ein Limit bergen. Die Länge eines Can-Buses ist durch die Signallaufzeit begrenzt. Zeit ist das wichtige Wort. Eine optische Trennung hat z.b. 25ns Delay. Das entspricht gleich mal 5m Leitungslänge. Hintergrund ist der, der Sender legt seine Signale auf den Bus. Der Empfänger liest das ein. Am Ende eines Telegrammes lässt der Sender den Bus los (rezesiv), und der Empfänger sendet dort sein "Acknowledge" (dominant). Der Sender kennt jetzt die Buslänge nicht und erwartet das Acknowledge synchron zu den anderen Bits. Der Empfänger sieht ja das Telegram um genau eine Signallaufzeit später und legt somit das ACK auch eine Signallaufzeit später auf den BUS. Das Ack ist also von Sender aus gesehen um zwei Signallaufzeiten verzögert. Wenn der Bus zu lang wird, dann ist das einfach ACk zu spät und der Sender liest ein NoAck. Deshalb geht mit niedriger Datenrate auch mehr Leitungslänge. Und passive Repeater helfen dagegen genau gar nichts.
> Deshalb geht mit niedriger Datenrate auch mehr Leitungslänge. Und > passive Repeater helfen dagegen genau gar nichts. Danke für die Klarstellung, aber dann entstehen glaube ich nur noch mehr Probleme. Ich könnte dann ca. 10 kbit/s setzen auf eine Leitungslänge von 5,5km, dann wären es nur 2 Segmente, aber dann gibt es zu viele Knoten pro Segment.
Hallo Lucas, Lucas schrieb: > Alle 1000 Meter ein CAN-FD Gateway für eine Bandbreite von bis zu > 50kbit/s > => maximal 46 Knoten pro Segment. > > Die Knoten melden Ereignisbasiert und nicht zu oft. Würde das so > funktionieren? Nein. Das wäre eher eine Anwendung für Single Pair Ethernet (SPE), konkret 10Base-T1L [1]. Mit freundlichen Grüßen Thorsten Ostermann [1] https://www.elektronik-kompendium.de/sites/net/2706091.htm
> Deshalb geht mit niedriger Datenrate auch mehr Leitungslänge. Und > passive Repeater helfen dagegen genau gar nichts. Das ist einer der Vorteile von CAN FD wenn man an diese Grenze kommt. Bei CAN FD wird nach der Arbitrierung, als wenn klar ist wer senden darf, auf eine höhere Bitrate geschaltet weil ab da die Einschränkung der Signallaufzeit auf eine ca. halbe Bitlänge weg fällt.
Lucas schrieb: > Zu den Stichleitungen kann ich nichts > genaues sagen ich vermute 50cm bis 1m. Bei 11km spielen die wohl keine Rolle, auch nicht, wenn es 500 sind. M.E. schreit das nach P2P. Die Stichleitung dann halt 4-polig ausführen (2x2), mit Blindstecker dort, wo ein Device abgenommen wird. Für uns ist die Aufgabenstellung aber völlig unklar. CAN, 485, EtherCat sind unterschiedliche Konzepte, was z.B. die Adressierung angeht.
Lucas schrieb: > Würde das so funktionieren? Offiziell wirbt CAN damit, dass das geht. 1000m bei 50kbps und Gateways (statt Repeater) wenn länger. Praktisch ist es hirnrissiger Unsinn. So ein langes Kabel ist eine Antenne und fängt sich alle denkbaren Störungen ein, vor allem wenn in der Nähe ein Blitz einschlägt sind deine Gateways kaputt. CAN ist für Mobile Fahrzeuge (und macht selbst dort bei hoher Datenrate Probleme ohne Ende). Nutze Glasfaser wenn du 11km per Leitung überbrücken willst. Keine Störungs- und Potentialprobleme. Halte die elektrisch verbundenen Bereiche klein. Ja, Telefon ging früher quer durchs Land nur mit einem Kupferdraht. Die Post hatte mit Überspannungen aber auch zu kämpfen. Auch Stromnetze spannen tausende Kilometer. Geben aber gei ordentlichem Nordlicht schon mal auf.
Bei deinen Anforderungen mit 11 km und 500 Knoten würde ich dir ganz klar zu RS485 raten. Das ist für solche Längen einfach besser geeignet als CAN - bewährt, kostengünstig und mit Standardbauteilen wie dem MAX485 umsetzbar. Die Master/Slave-Architektur kommt ohne den CAN-Protokoll-Overhead aus und du vermeidest die ganzen Probleme mit Signalintegrität und teuren Gateways. Wenn's unbedingt mehr Bandbreite sein muss, könntest du dir noch 10Base-T1L (Single Pair Ethernet) anschauen, aber RS485 ist hier wahrscheinlich die pragmatischste Lösung. Und ganz wichtig: Vergiss auf keinen Fall die galvanische Trennung und ordentlichen Blitzschutz, bei 11 km Leitungslänge wirst du dir sonst früher oder später die Haare raufen, wenn die erste Gewitterfront durchzieht.
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.