Guten Tag zusammen, Ich möchte mich hier an das Form wenden, da es sicherlich viele versierte Menschen hier gibt die mir mit meinem "Problem" helfen können. Ich suche nach einer Modernen Bustechnologie (zeitgemäss) Ein Gerät (Betriebsspannung 3.3V, LIPO Akku) soll mit einer Bustechnologie vernetzt werden, aufgrund der Baulage kommt nur eine "Sternverkabelung" in Frage. Entweder muss vom Master je ein Kabel zu einem Slave gelegt werden, oder es wird ein "Hauptstrang" verlegt an welchen die Slaves über kurze sogenannte Stubs angeschlossen wird. Ebenfalls ist es in Planung die Geräte per Kabel (optional) mit Strom zu versorgen (Die Versorgungspannung sollte im Bereich 5-12V liegen, und wird dann per SMPS auf 3.3V gewandelt werden und dient als Akku alternative). Somit kann auch eine Bustechnologie in Frage kommen welche gleich Spannung mitliefert. Folgende weitere Details kann ich zu der Sachlage liefern: - Der Bus kommuniziert nur einseitig. Der Master fragt nicht einzelne Slaves an, sondern die Slaves senden einfach Ihr Datenpaket. Für Zukünftige Anwendungen wäre es ein Bonus wen die Bustechnologie auch zweiweg Kommunikation unterstützt - Der Bus darf nicht Hardwareadressiert, oder "geschlauft" - Die "Strangleitung" ab Master ist ca. 20m lang, die einzelnen Stub-Abgänge jeweils 2m. Pro Strang sollten ca. 20-30 Slaves anhängbar sein - Die Datenrate ist extrem wechselnd, für einen Moment müssen 32 BYTE versendet werden, dann ist aber in der Regel wieder für >1h ruhe. Das zwei Slaves zur exakt selben Zeit senden, ist nahezu ausgeschlossen - Im Idealfall ist der Bus so aufgebaut, das einzelne Slaves einfach entfernt oder zugeschaltet werden können, ohne das der Master etwas machen muss. - Der Bus sollte einen alltagstauglichen Aufbau haben (keine Spezialkabel wie z.b. LVDS) - Je weniger externe Hardware nötig, je besser. Im Idealfall kann der Bus direkt an einen MCU angebunden werden. Ich hoffe genügend Daten geliefert zu haben, und hoffe nun auf einige Ratschläge welche Bustechnologie eingesetzt werden kann Grüsse Jazeel
Klingt definitiv nach CAN. Etwas einfacher wäre ggf. MODBUS (RS485), wobei das auch nicht "modern" ist, dafür robust. Sehr speziell würde dann ggf. noch IO-Link gehen, aber das würde einen sehr großen Rattenschwanz mit sich ziehen
:
Bearbeitet durch User
>Das >zwei Slaves zur exakt selben Zeit senden, ist nahezu ausgeschlossen Das kann sich zu einem Debug-Albtraum entwickeln. Das darf keine Säule sein, auf die man aufbaut. Da der vorgeschlagene CAN mit "Carrier Sense Multiple Access/Collision Detection (CSMA/CD)" arbeitet, währe das Thema vom Tisch.
Jazeel Jeybalan schrieb: > Der Bus kommuniziert nur einseitig. Der Master fragt nicht einzelne > Slaves an, sondern die Slaves senden einfach Ihr Datenpaket. Das ist sehr ungünstig. Was ist der Hintergrund für diese Anforderung?
Jazeel Jeybalan schrieb: Dein Eröffnungsbeitrag verwirrt mich. Ich würde empfehlen, zuerst die Unstimmigkeiten zu klären, bevor wir über technische Lösungen diskutieren. Das widerspricht sich: > aufgrund der Baulage kommt nur eine "Sternverkabelung" in Frage. > ... es wird ein "Hauptstrang" verlegt an > welchen die Slaves über kurze sogenannte Stubs angeschlossen wird. Das widerspricht sich: > Der Bus kommuniziert nur einseitig. Der Master fragt nicht einzelne > Slaves an, sondern die Slaves senden einfach Ihr Datenpaket. Wenn mehrere Teilnehmer einfach ihre Datenpakete senden, dann hast du kein Master/Slave Konzept. Man nennt das dann eventuell Multi-Master. Das ist missvertändlich: > Der Bus kommuniziert nur einseitig... > Für Zukünftige Anwendungen wäre es ein Bonus wen die Bustechnologie > auch zweiweg Kommunikation unterstützt Was genau meinst du damit? Für mich klingt das fast, wie die Unterscheidung zwischen bidirketionaler und unidirektionaler Kommunikation oder half-duplex versus full-duplex. > Die "Strangleitung" ab Master ist ca. 20m lang, die einzelnen > Stub-Abgänge jeweils 2m. Ich kenne keine Technologie, die so lange Abgänge an einem Bus mit 20-30 Teilnehmern zulässt. > Das zwei Slaves zur exakt selben Zeit senden, ist nahezu ausgeschlossen Und wenn doch? Was soll dann passieren? Kollisionserkennung mit Retry, wie bei Ethernet? Oder einfach ignorieren? > Im Idealfall kann der Bus direkt an einen MCU angebunden werden. Das kannst du vergessen. Keine mir bekannte MCU enthält Bustreiber. Macht auch wenig Sinn, denn die Bustreiber sollten für Reparaturen austauschbar sein.
Jazeel Jeybalan schrieb: > Das > zwei Slaves zur exakt selben Zeit senden, ist nahezu ausgeschlossen Wie wird dieser Ausschluß denn realisiert? Wenn man 30 Geräte mit der selben Firmware zur gleichen Zeit einschaltet, werden die auch gerne zur gleichen Zeit das gleiche machen wollen.
Würde auch sagen, dass RS485 für die Lösung als passabel erscheint.
Jazeel Jeybalan schrieb: > Der Master fragt nicht einzelne > Slaves an, sondern die Slaves senden einfach Ihr Datenpaket. Dann ist CAN das Mittel der Wahl. RS-485 ist ungeeignet, da der Master die Slaves erst zum Senden adressieren muß. RS-485 kann keine Kollisionen erkennen oder auflösen.
Jazeel Jeybalan schrieb: > - Die Datenrate ist extrem wechselnd, für einen Moment müssen 32 BYTE > versendet werden, dann ist aber in der Regel wieder für >1h ruhe. Das > zwei Slaves zur exakt selben Zeit senden, ist nahezu ausgeschlossen Du verlässt dich auf dein Gefühl, und das trügt dich: https://de.wikipedia.org/wiki/Geburtstagsparadoxon In der Praxis bedeutet das, dass du (gefühlt) laufend mit solchen Kollisionen zu tun hast. Und blöderweise kann es dann sein, dass "wenn sich zwei gefunden haben" mehrere Stunden lang die Telegramme zweier Slaves kollidieren. Du solltest dir also eine Strategie zur Kollisionsauflösung ausdenken. > (keine Spezialkabel wie z.b. LVDS) Wie kommst du bei LVDS auf "Spezialkabel"? Gerade LVDS (oder z.B. Derivate wie CAN, RS485) kommt wegen der differentiellen Übertragung mit simpler verdrillter Klingellitze aus...
Peter D. schrieb: > RS-485 ist ungeeignet, da der Master die Slaves erst zum Senden > adressieren muß. RS-485 kann keine Kollisionen erkennen oder auflösen. Sicher. Aber wenn man die kaputte Designentscheidung (Slaves senden unaufgefordert) weglässt und stattdessen ein sinnvolles Master-Slave-Konzept verwendet, funktioniert RS485 auch. Und RS485 kann man mit deutlich geringeren Datenraten betreiben als CAN, was die Angelegenheit robuster und vor allem deutlich toleranter bei der Verkabelung macht. Der schon angesprochene Modbus arbeitet üblicherweise mit 9600 Baud.
Jazeel Jeybalan schrieb: > - Der Bus kommuniziert nur einseitig. Der Master fragt nicht einzelne > Slaves an, sondern die Slaves senden einfach Ihr Datenpaket. und Jazeel Jeybalan schrieb: > - Der Bus darf nicht Hardwareadressiert, oder "geschlauft" und Jazeel Jeybalan schrieb: > - Im Idealfall ist der Bus so aufgebaut, das einzelne Slaves einfach > entfernt oder zugeschaltet werden können, ohne das der Master etwas > machen muss. klingt nach einer unmöglichen Anforderung und einem Alptraum für den Betrieb/Debugging. Was sind das für Slaves? Einfache Sensorknoten? Müssen die Slaves im Betrieb hinzufügbar sein? … Plug and Play ohne Adressierung beim Slave wird wohl eher in die Richtung TCP/IP mit DHCP Server (würde von der Topologie und den Längen auch passen) oder USB gehen. Oder du baust dir selber ein Protokoll auf, dass beim Hochfahren des Busses zuerst alle Slaves durchgeht und denen eine definierte Adresse vergibt. Einfach sendende Slaves finde ich extrem unpraktisch, ausser du hast mehrere Master. Aber um eine sehr intelligente Software wirst du nicht herumkommen.
Loconet: http://www.digitrax.com/support/loconet/home/ kann das alles - aber ob das unter "modern" fällt, weiß ich nicht :D Ist allerdings öffentlich nur mäßig genau spezifiziert und wer es kommerziell einsetzt, wird lizenzpflichtig. Und es ist ein sehr spezielles Bussystem als Lösung für ein sehr spezielles Problem... MfG, Arno
Vor 15 Jahren habe ich das mal mit AVRs gemacht um Temperaturen und Luftfeuchte in einer Orangerie an vielen Stellen zu messen. Am AVR hingen einfach Transistoren die als Open-Kollektor auf einen gemeinsamen Widerstand arbeiten. Den kann man dann ausreichend niederohmig machen. Natürlich kommt es zu Kollisionen, das passiert bei Funk auch ständig. Also ist eine ordentliche Checksummenprüfung Pflicht die den Müll verwirft. Und unterschiedliche Zeiten pro Adresse, am besten noch etwas Zufall. Bei mir waren 1200Baud mehr als ausreichend um alle ca. 2min die Meßstellen zu erfassen. Verkabelt war das mit einfachem 2paarigen Telefonkabel was es überall gibt. Ob das heute noch modern ist? Sicher nicht. Aber trotzdem robust. Den Temperaturen- und Feuchtewerten sieht man übrigens auch heute noch nicht an dass sie unmodern gemessen werden.
temp schrieb: > Am AVR > hingen einfach Transistoren die als Open-Kollektor auf einen gemeinsamen > Widerstand arbeiten. Den kann man dann ausreichend niederohmig machen. Wenn man dann noch das Datensignal auf einen Pin des MC zurückführt, wäre sogar eine einfache Kollisionserkennung möglich, ähnlich wie bei I²C. Wenn das Signal low ist, obwohl ich 'high' sage, muss ein anderer gerade den Draht besetzen.
Rufus Τ. F. schrieb: > Und RS485 kann > man mit deutlich geringeren Datenraten betreiben als CAN CAN kann man auch mit niedrigen Datenraten betreiben und kommt dann kilometerweit oder kann viele lange Stichleitungen machen, das ist also kein Argument.
Rufus Τ. F. schrieb: > Sicher. Aber wenn man die kaputte Designentscheidung (Slaves senden > unaufgefordert) weglässt Das ist per se keine kaputte Designentscheidung, das kann zum Beispiel so gewollt sein weil es in der konkreten Anwendung mehr Sinn ergibt und weniger Buslast erzeugt und geringere Lazenzen als wenn der Master ständig mit Vollgas reihum zwölfunddreißig Slaves pollen muß die allesamt 99.999% der Zeit nichts neues zu vermelden haben. Oder willst Du etwa auch Ethernet oder CAN als "kaputt by Design" bezeichnen?
:
Bearbeitet durch User
Verteilte Bus-Master bringen doch nur etwas, wenn man auch verteilte Auswertelogiken hat. Idee dahinter ist doch, dass nur Änderungen auf den Bus gegeben werden, die dann bearbeitet werden. Wenn eh alles im Master berechnet wird, ist es besser einen Master/Slave Bus zu nehmen und damit Kollisionen zu umgehen. Alternative: TT-CAN
Jazeel Jeybalan schrieb: > Entweder muss vom Master je ein Kabel zu > einem Slave gelegt werden, oder es wird ein "Hauptstrang" verlegt an > welchen die Slaves über kurze sogenannte Stubs angeschlossen wird. >.... > - Die "Strangleitung" ab Master ist ca. 20m lang, die einzelnen > Stub-Abgänge jeweils 2m. Pro Strang sollten ca. 20-30 Slaves anhängbar > sein Am besten geht das wohl mit slew rate limited RS485 Treibern ohne Abschlußwiderstände. Wobei du das schon angesprochene Kollisionsszenario welches dir garantiert irgendwann mal Probleme machen wird, durch ein richtiges Master/Slave Konzept in den Griff kriegen solltest. Mit aktuellen CAN Treibern müßtest du eine Mindestdatenrate einhalten. Weiters hast du bei so einem Aufbau das Problem, dass es keine optimalen Positionen für die zwingend notwendigen Abschlußwiderstände gibt. Dafür könntest das Kollisionsszenario elegant und einfach in SW lösen. Ich würde bei so einem Aufbau mit CAN statt der üblichen 2 Abschlußwiderständen nur einen beim Master einbauen und relativ hochohmige bei jedem Slave UND externe RC bei den Treibern dazubauen um die slew rate zu begrenzen. Oder einen nicht so modernen/billigen CAN Treiber nehmen bei dem man noch die slew rate einstellen kann. Mit Standard CAN hat das aber nicht mehr viel zu tun außer dem billigen und robusten Treiber IC. Darüber würd ich ein Standard UART Protokoll empfehlen. Außer du hast eh so einen "teuren" Mikrcontroller der CAN Behandlung in HW drinnen hat.
:
Bearbeitet durch User
Andi B. schrieb: > Mit aktuellen CAN Treibern müßtest du eine Mindestdatenrate einhalten. Zeig mir einen.
Stefanus F. schrieb: > Das ist missvertändlich: >> Der Bus kommuniziert nur einseitig... >> Für Zukünftige Anwendungen wäre es ein Bonus wen die Bustechnologie >> auch zweiweg Kommunikation unterstützt > > Was genau meinst du damit? Für mich klingt das fast, wie die > Unterscheidung zwischen bidirketionaler und unidirektionaler > Kommunikation oder half-duplex versus full-duplex. Ich meine damit nur das ich keinen Bus möchte, der eine ständige Verbindung braucht. Nehmen wir RS232 als Beispiel. Öffnet man eine Konsole an einem RS232 port kann man direkt Daten empfangen, kappt man den Node und hängt z.b. einen komplett anderen an, ist das dem RS232 egal, es werden direkt neue Daten empfangen. Der Master soll im Idealfall nur "hören". Er empfängt Datensätze und löst daraufhin eine Aktion aus. Es gibt ja auch Bus-Systeme die man initialisieren muss, und wenn die Verbindung einmal weg ist, muss Sie neu aufgebaut werden. Wichtig ist auch, das der Slave (bzw. Device) keine Kentniss über den Master haben muss, es werden also einfach Daten auf den Busport rausgehauen, egal ob ein Bus da ist oder nicht, oder was auf der anderen Seite ist. Da die Applikation der Geräte sehr unterscheided, ist eine zeitlich gesteuerte "Anfrage" vom Master nur ein energiefresser. Die Slaves befinden sich beim Status "unused" im Schlafmodus (1uA), werden sie von einem Bediener verwendet wechseln sie im "Startup" auf kurzzeitig mehrer mA und dann in den Satus "used" (40uA). Beim "Shutdown" wechseln sie von 40uA auf (1uA). Für "used" und "unused" soll ein Telegramm inkl. Statistikwerte versendet werden Ein Device kann 0mal, 1mal oder 5mal pro Tag genutzt werden. Bei 5 mal kann das alle 3h sein, aber auch 5mal in einer 1h. Somit kann man nicht einfach "alle x" die Slaves anfragen. Man müsste schon im 10s Takt anfragen, aber dafür müsste man natürlich jedesmal den Slave wecken. Bei Batteriebetrieb geht dies auf die Lebenszeit. > Und wenn doch? Was soll dann passieren? Kollisionserkennung mit Retry, > wie bei Ethernet? Oder einfach ignorieren? Die Pakete der Nodes sind nur statistischer Natur und haben keinen "funktionellen Inhalt" - sollte der äusserst seltene Fall eintreffen, das zwei Nodes gleichzeitig senden, kann die Transaktion ignoriert werden. Der Fall ist übrigens fast nicht möglich. Damit dies möglich wird, müssen zwei Bediner exakt zur gleichen Zeit das Device aufwecken, exakt genau gleich schnell in der Bedienung sein und dann wird auch noch im genau gleichen Moment die Transaktion abgesetzt. Da eine Transaktion vermutlich wenige ms dauert, ist das praktisch eigentlich garnicht machbar. Vorallem bei nur 20-30 Nodes pro Strang. Bei 1000 Nodes wäre der Zufallspunkt wohl wesentlich höher. > Das kannst du vergessen. Keine mir bekannte MCU enthält Bustreiber. > Macht auch wenig Sinn, denn die Bustreiber sollten für Reparaturen > austauschbar sein. Meinst du mit Bustreiber Hardwarebausteine (also wie z.b. den MAX232 bei Serial) das ist kein Problem, ich möchte nur eine weitere Logikeinheit (MCU oder ähnlich) verwenden. Also nicht "MCU->SPI->Busbausteinlogik->Bus" sondern "MCU->Bushardaware->Bus", also die Software zum Bus soll direkt im MCU möglich sein.
Jazeel Jeybalan schrieb: > Der Fall ist übrigens fast nicht möglich. D.h. er ist nicht ausgeschlossen. So wie der 49,7 Tage-Bug: https://www.cnet.com/news/windows-may-crash-after-49-7-days/ Bei CAN gibt es damit keinerlei Probleme. Der unterlegene Sender wartet, bis der andere fertig ist und sendet nochmal, ganz ohne jeden Softwareoverhead. Bei RS-485 braucht man eine zusätzliche Software, die eine Fehlererkennung und Retry ausführt. Ansonsten sind beide Datensätze korrupt.
In Zeiten von IoT wäre das doch ohne Kabel direkt über z.B WLAN NodeMCU's .. und nem Server zu realisieren. MQTT oder ähnliches. Ethernet DHCP .. A ist das modern GRINS B es funktioniert C es gibt schon einiges fix und fertig.
Jazeel Jeybalan schrieb: > Der Master soll im > Idealfall nur "hören". Er empfängt Datensätze und löst daraufhin eine > Aktion aus... > Wichtig ist auch, das der Slave (bzw. Device) keine Kentniss über den > Master haben muss, es werden also einfach Daten auf den Busport > rausgehauen, egal ob ein Bus da ist oder nicht, oder was auf der anderen > Seite ist. Du solltest mal den Begriffswirrwarr in deinem Hirn aufräumen:-) Das was du hier z.B. beschreibst ist eben kein Master sondern eine Client. Und dein "Client" ist der (Multi)Master... Das was du vorhast hört sich nicht mal ansatzweise nach einer klassischen Master/Slave(Client) Architektur an. Das ganze schreit aber schon recht stark nach CAN. Unzählige Gerät plappert munter auf dem Bus herum egal ob es irgendeinen Empfänger wirklich interessiert oder nicht und des Gerät das es ggf. interessiert "abonniert" die für ihn interessante Meldungsnummern und verarbeitet diese dann. Das händelt aber nahezu alles die Hardware für dich. Einziger Nachteil, irgendein Gerät muss den Absendern gelegentlich auch mal ein Ackowledgemen schicken (auch wenn der Inhalt selbst uninteressant ist) damit die Meldung nicht dauernd wiederholt wird und irgendwann das senden eingestellt wird. Nur eine gerät allein sendet nicht wirklich in die "Luft". Aber egal welches Bussystem du verwenden wirst, bei deinem recht speziellen Design wirst du immer irgendwelche Kompromisse eingehen müssen damit es überhaupt einigermaßen funktioniert.
Mir scheint, die theoretisch möglichen Kollisionen werden hier etwas überbewertet. Viel spannender finde ich den Batteriebetrieb: Jazeel Jeybalan schrieb: > Die Slaves befinden sich beim Status "unused" im Schlafmodus (1uA), > werden sie von einem Bediener verwendet wechseln sie im "Startup" auf > kurzzeitig mehrer mA und dann in den Satus "used" (40uA). Beim > "Shutdown" wechseln sie von 40uA auf (1uA). Um in die Nähe von 1uA zu kommen, muss man im Shutdown die Stromversorgung der Bus-Transceiver abschalten, auch ICs mit Disable-Eingang werden nicht so sparsam. Nur gut, dass die Slaves nichts empfangen sollen... Der Master muss natürlich immer empfangsbereit sein, damit wird der Stromverbrauch vom Bus-Empfänger bestimmt. Ein normaler Transceiver kommt also garnicht in Frage. Ein einzelner RS485-Empfänger ist besser, aber der sparsamste, den ich kenne (ISL32612E), braucht auch noch 135uA(max). Ein sparsamer Transceiver (ISL3172E) braucht 700uA bzw. 800uA beim Senden. Für die Slaves wäre der allerdings gut. Gibt es eigentlich ähnlich sparsame CAN-Transceiver? Insofern ist ein "moderner Bus" nicht die erste Wahl. Bei 22m Kabel, minimaler Datenrate und Batteriebetrieb ist die differentielle Übertragung evt. auch übertrieben. Wenn die Slaves potentialfrei sind, ist eine Datenader plus Masse quasi auch differentiell. Dafür müsste der Master-Empfänger keine besondere Gleichtaktunterdrückung können. temp schrieb: > Am AVR > hingen einfach Transistoren die als Open-Kollektor auf einen gemeinsamen > Widerstand arbeiten. Den kann man dann ausreichend niederohmig machen. Damit hat man sowas wie einen Stromschleifen-Bus. Mit Stromschleifen hat man früher Kilometer überbrückt. In den uCs benutzt man UARTs, z.B. mit 9600 Baud. Das Beste: der Ruhestrom ist auf beiden Seiten Null (na gut, Leckströme). Solange der Master nicht senden muss, könnte über eine Datenader plus Masse könnte sogar die Stromversorgung der Slaves laufen. Der Master-Empfänger müsste nur eine Schaltschwelle bei einem bestimmten Strom haben.
Erik schrieb: > Andi B. schrieb: >> Mit aktuellen CAN Treibern müßtest du eine Mindestdatenrate einhalten. > > Zeig mir einen. TJA1057
Hallo, > Jazeel Jeybalan schrieb: > Ich suche nach einer Modernen Bustechnologie (zeitgemäss) ich denke, deine Aufgabenstellung hat gar nichts mit "modern" oder alt zu tun, sondern vielmehr damit, sehr spezielle Anforderungen zu erfüllen. > Ein Gerät (Betriebsspannung 3.3V, LIPO Akku) soll mit einer > Bustechnologie vernetzt werden, aufgrund der Baulage kommt nur eine > "Sternverkabelung" in Frage. Entweder muss vom Master je ein Kabel zu > einem Slave gelegt werden, oder es wird ein "Hauptstrang" verlegt an > welchen die Slaves über kurze sogenannte Stubs angeschlossen wird. Da fehlen zunächst konkrete Werte zu Datenmengen und Datenraten. Weiter unten schreibst du aber, dass nur wenige Bytes in eher sehr großen Abständen (Minuten bis Stunden) übertragen werden sollen. Dazu kommt, dass der BUS nur paar 10m lang sein soll. Ich nehme auch an, dass der Betrieb in nicht stark störbehafteter Umgebung erfolgt und nach der Beschreibung ist hohe Zuverlässigkeit eh kein kritisches Thema, oder? > Ebenfalls ist es in Planung die Geräte per Kabel (optional) mit Strom zu > versorgen (Die Versorgungspannung sollte im Bereich 5-12V liegen, und > wird dann per SMPS auf 3.3V gewandelt werden und dient als Akku > alternative). Somit kann auch eine Bustechnologie in Frage kommen welche > gleich Spannung mitliefert. Bei deinen Anforderungen sind die Anforderungen einerseits sehr viel einfacher, als übliche Bus-Systeme leisten müssen. Dafür ist das Thema Strombedarf primär wichtig. Der Physical Layer kann also sehr viel einfacher gestaltet werden, als es bei üblichen Bus-Systemen sonst üblich ist. Ich empfehle dir einen einfachen Bus mit Übertragung von Spannungspegeln. Das kann bei den geringen Anforderungen auch mit TTL-Pegeln (5V oder auch 3,3V) erfolgen. Die Verwendung von leistungsfähigen Bus-Tranceivern ist da gar nicht nötig und passt auch nicht so gut zum Thema "Strom sparen" wegen Akkubetrieb. > Folgende weitere Details kann ich zu der Sachlage liefern: > - Der Bus kommuniziert nur einseitig. Der Master fragt nicht einzelne > Slaves an, sondern die Slaves senden einfach Ihr Datenpaket. Bei den gegenene Bedingungen würde das wohl schon ohne spezielle Maßnahmen zu fast 100% funktionieren. Die Zuverlässigkeit könnte man durch eine wiederholte Übertragung (2...3 mal) mit zufällig gewählten Zeitabständen im Sekundenbereich verbessern. Mit dem Prinzip der Busarbitrierung bei CAN sind aber auch Datenkonflikte zu vermeidbar. Allerdings bedingt das ja auch schon, dass die Busteilnehmer auch empfangen können. In dem Fall kann man aber auch Datenkonflikte durch das Protokoll abfangen und bei Bedarf eine Wiederholung anfordern. Bei Trennung von Sende- und Empfangsleitungen (mind. 3 Drähte) wäre ein Request von der MCU zu den Sensoren aber auch kein Thema. > Für zukünftige Anwendungen wäre es ein Bonus wen die Bustechnologie > auch zweiweg Kommunikation unterstützt Ja wo ist das Problem. Mithören am Bus geht mit minimalem Aufwand auch sehr stromsparend. Zum Senden von TTL-Pegel gibt es Treiber mit Tri-State-Ausgängen. In CMOS-Technologie brauchen die nur paar uA Ruhestrom. > - Der Bus darf nicht Hardwareadressiert, oder "geschlauft" Wenn es bidirektional werden soll, wäre es aber schon irgendwie notwendig, entweder die BUS-Teilnehmer zu addressieren oder wie bei CAN die Nachrichten mit Identifiern zu kennzeichnen. Bei einem Bus mit Rückleitungen (3-Draht) wäre auch die einfache Quitierung innerhalb einer def. Zeit vorteilhaft. > - Die "Strangleitung" ab Master ist ca. 20m lang, die einzelnen > Stub-Abgänge jeweils 2m. Pro Strang sollten ca. 20-30 Slaves anhängbar > sein Physikalisch sind das sehr einfache und günstige Bedingungen. Ich empfehle eine niedrige Baudrate (z.B. 1200 Baud oder weniger) mit deutlich Bandbreite begrenten Signalen (Tiefpass). Damit sind jegliche HF-Effekte raus und der Bus muß nicht terminiert werden (geringer Leitungsbedarf). Auf dem Bus kann mit recht hochohmigen Pull-Down-R ein Ruhepegel definiert werden. > - Die Datenrate ist extrem wechselnd, für einen Moment müssen 32 BYTE > versendet werden, dann ist aber in der Regel wieder für >1h ruhe. Das ist nicht die "Datenrate", sondern eher das Datenaufkommen. > Das zwei Slaves zur exakt selben Zeit senden, ist nahezu ausgeschlossen Du mußt wissen ob der seltenen Fall von Datenkonflikten akzeptiert werden kann. > - Im Idealfall ist der Bus so aufgebaut, das einzelne Slaves einfach > entfernt oder zugeschaltet werden können, ohne das der Master etwas > machen muss. Wenn die eh passiv sind, gibt es auch keine Probleme damit, sofern du keine solchen Mechanismen im Protokoll anforderst. > - Der Bus sollte einen alltagstauglichen Aufbau haben (keine > Spezialkabel wie z.b. LVDS) Im einfachten Fall reicht einfacher Klingeldraht. Wenn dieser verdrillt ist (TP - twistetd pairs), ist es umso besser. Einfache TP-Signalkabel mit Schirmung verbessern die Störmepfindlichkeit nochmal deutlich, sofern der Schirm korrekt auf Erde gelegt werden kann. > - Je weniger externe Hardware nötig, je besser. Im Idealfall kann der > Bus direkt an einen MCU angebunden werden. Kann man machen. Allerding sollten uC-Ports besser mit einem Leitungstreiber entkoppelt werden. Schutzbeschaltungen sind auf alle Fälle zu empfehlen (siehe unten). > Ich hoffe genügend Daten geliefert zu haben, und hoffe nun auf einige > Ratschläge welche Bustechnologie eingesetzt werden kann Es gibt trotz der sehr einfachen Möglichkeiten zu beachten, dass Überspannungsschutz (z.B. durch Blitzschlag bei Gewitter) in ausreichendem Maße realisiert ist. Das ist aber wegen der niedrigen Baudrate leicht mit Suppressordioden zu bewerkstelligen. Eingänge können eh recht hochohmig gemacht werden. Die empfohlenen Leitungen mit Verdrillung und Schirm sind diesbezüglich auch vorteilhaft. Gruß Öletronika
Jazeel Jeybalan: Du willst kein (Single-Master/Multi-Slave)-Netzwerk sondern ein (Multi-Master/Single-Slave)-Netzwerk. Dieses Wissen könnte dir helfen bei der Recherche im Internet. Master = Netzwekteilnehmer, der eine Kommunikation "lostritt" (salopp gesagt). Dein "Master" hört ja nur zu und ist somit eigentlich ein Slave und deine "Slaves" sind eigentlich Masters. Wenn es einfach sein muss, dann schau dir die Hardware vom LIN-Bus an, da geht nix kaputt, wenn mal 2 gleichzeitig senden. Ich verwende es in meiner Aquariensteuerung mit diversen Slaves, jedoch habe ich mein eigenes Protokoll geschrieben, dass mehr Payload hat (auch habe ich die LIN-Treiber einfach selbst gemacht aus zwei LocigLevel-N-MOSFETs + TVS). Du brauchst dafür drei Drähte (12V-Versorgung, GND, LIN-Leitung) und gut ist. Wenn du Unterlagen brauchst oder Schaltungsbeispiele, dann schick mir eine PM. So oder so: Wenn alle Master unkontrolliert senden können sollen, so würde ich dir zumindest beim Slave empfehlen, dass der den Empfang bestätigt (z.B. schickt er ein XOR-Byte aller empfangenen 32 Bytes gleich im Anschluss zurück, der sendende Master kann somit überprüfen, ob seine Daten angekommen sind). Denn wie schon geschrieben: Wenn du alle Teilnehmer gleizeitig einschaltest, werden die sich tendenziell gleich verhalten (auch zeitlich), und somit kann es vorkommen, dass immer irgendwelche gleichzeitig senden - und das über längere zeit. ps: (Single-Master/Multi-Slaves)-Netzwerk ist massiv einfach zu implementieren als andersrum. Da gibt es auch ansätze, dass der Master periodisch (z.B. alle 30 Sekunden) nach neuen Slaves sucht, die vom Master noch keine zugewiesene Adresse erhalten haben.
:
Bearbeitet durch User
Master S. schrieb: > Denn wie schon geschrieben: Wenn du > alle Teilnehmer gleizeitig einschaltest, werden die sich tendenziell > gleich verhalten (auch zeitlich), und somit kann es vorkommen, dass > immer irgendwelche gleichzeitig senden - und das über längere zeit. Nicht, wenn die eine vernünftige Software haben. Genau um solche vorprogrammierten Überschneidungen zu vermeiden, wird der genaue Zeitpunkt der Aussendung über einen Zufallsparameter beeinflusst und vorher geguckt, ob der Bus frei ist.
Andi B. schrieb: >>> Mit aktuellen CAN Treibern müßtest du eine Mindestdatenrate einhalten. >> >> Zeig mir einen. > > TJA1057 Datenrate mit Baudrate verwechselt?
rcc schrieb: > Andi B. schrieb: >>>> Mit aktuellen CAN Treibern müßtest du eine Mindestdatenrate einhalten. >>> >>> Zeig mir einen. >> >> TJA1057 > > Datenrate mit Baudrate verwechselt? Ja, mein Fehler. Auch weil kurz vorher geschrieben wurde, CAN könne auch bei "niedriger Datenrate kilometerweit und mit vielen Stichleitungen".
Andi B. schrieb: > Ja, mein Fehler. Und ich wollte gerade antworten... ;) Andi B. schrieb: > CAN könne auch bei "niedriger > Datenrate kilometerweit und mit vielen Stichleitungen" Das kann es natürlich nicht. Liegt aber daran dass es bitbasiert ist. Ein "UART mit CAN Phy" könnte allerdings sehr wohl wesentlich weiter kommen.
Hallo, Erik schrieb: > Andi B. schrieb: >> CAN könne auch bei "niedriger >> Datenrate kilometerweit und mit vielen Stichleitungen" > > Das kann es natürlich nicht. Doch, kann er ;-) Folgende Empfehlungen zur Leitungs-/Stichleitungslänge gilt für den CAN:
1 | baud rate Leitungslänge Stichleitung (einzeln) Stichleitungen (gesamt) |
2 | 50 kbit/s 1000 m 50 m 250 m |
3 | 125 kbit/s 500 m 20 m 100 m |
4 | 250 kbit/s 250 m 10 m 50 m |
5 | 500 kbit/s 100 m 5 m 25 m |
6 | 1 Mbit/s 20 m 1 m 5 m |
Und mit dem genannten TJA1057 kann man problemlos 50 kbit/s einstellen (minimal 0.6 ms time-out). Damit lässt sich eine (ein) Kilometer lange CAN-Leitung mit vielen (insgesamt 250m langen) Stichleitungen darstellen. In der Praxis kann man einen 50kbit/s - CAN praktisch nicht durch die Leitungsführung kaputt machen. Schöne Grüße, Martin
Bauform B. schrieb: > Ein sparsamer Transceiver (ISL3172E) braucht 700uA bzw. > 800uA beim Senden. Für die Slaves wäre der allerdings gut. Gibt es > eigentlich ähnlich sparsame CAN-Transceiver? Z.B. der AT6560 braucht im Standby max 12µA. Ein dominanter Pegel läßt ihn aufwachen, d.h. der Empfangsteil bleibt aktiv.
Martin L. schrieb: > Doch, kann er ;-) Folgende Empfehlungen zur Leitungs-/Stichleitungslänge > gilt für den CAN: > baud rate Leitungslänge Stichleitung (einzeln) Stichleitungen > (gesamt) > 50 kbit/s 1000 m 50 m 250 m > 125 kbit/s 500 m 20 m 100 m > 250 kbit/s 250 m 10 m 50 m > 500 kbit/s 100 m 5 m 25 m > 1 Mbit/s 20 m 1 m 5 m Du kannst sogar noch ne Null an der Bitrate wegnehmen und dann reicht der CAN-Bus bis ins Nachbardorf, mit Stichleitungen an jedem Gartentürchen, es spricht nichts dagegen notfalls auf 10kHz oder gar 5kHz runterzugehen.
Martin L. schrieb: > baud rate Leitungslänge Stichleitung (einzeln) Stichleitungen > (gesamt) > 50 kbit/s 1000 m 50 m 250 m > 125 kbit/s 500 m 20 m 100 m > 250 kbit/s 250 m 10 m 50 m > 500 kbit/s 100 m 5 m 25 m > 1 Mbit/s 20 m 1 m 5 m Kannst du mir die Quelle für diese Werte nennen? Das Problem mit den Stichleitung kommt bei uns häufiger vor. Grüße
Bernd K. schrieb: > es spricht nichts dagegen notfalls auf 10kHz oder gar > 5kHz runterzugehen. Bei 10 kbit/s werden es 6,7km Leitungslänge. https://www.me-systeme.de/de/support/grundlagen/can-bus-grundlagen Mit welchem Widerstand terminiert man solche Buslängen?
Thomas F. schrieb: > Mit welchem Widerstand terminiert man solche Buslängen? Mit dem Wellenwiderstand der verwendeten Leitung, wie sonst auch. Allerdings machen einem die Abzweigungen von Stichleitungen die schöne Rechnung wieder kaputt. Jedoch bei solch niedrigen Bitraten dürften Reflexionen eh keine große Rolle mehr spielen.
:
Bearbeitet durch User
Hallo, ein paar Randbedingungen sollte man bei der ganzen Sache dann doch noch beachten. > Simon T. schrieb: > Kannst du mir die Quelle für diese Werte nennen? Das Problem mit den > Stichleitung kommt bei uns häufiger vor. Bei Stichleitungen hat man ja das Problem, dass diese nicht alle terminiert werden können, weil der Signalpegel dadurch unzulässig reduziert würde. Ob aber unterminierte Leitungen Probleme machen, hängt nicht primär von der Baudrate ab, sondern vom Frequenzsprektrum des Signals. Diese ist aber hauptsächlich von der Flankensteilheit der Bits abhängig. Wenn die Baudrate auch nur 10kHz beträgt, man aber Treiber für eine max. Baudrate von 10MHz benutzt, muß man mit Oberwellen bis über 50Mhz rechnen und bekommt auch schon bei paar 10m langen Leitungen kräftige Reflexionen. Als Faustformel gilt: Eine Leitung ist ab ca. Lambda/10 als Wellenleiter zu betrachten. Spätestenz ab Lambda/4 hat man deutliche HF-Effekte auf nicht korrekt terminierten Leitungen. Lambda ist dabei die höchste Frequenz mit noch relevanter Amplitude. Wenn man also nur 10kBaud übertragen muß, dann sollte man tunlichst die Bandbreite des Signals begrenzen (also Flankensteilheit reduzieren). Mit Oberwellen im Bereich bis 50MHz und höher werden dann schon Stichleitungen unter 1m Länge kritisch. Bei Begrenzung der Bandbreite auf 100kHz sind aber auch Stichleitungen bis über 100m unproblematisch. Die oben von Martin L. aufgeführten Leitungslängen beziehen sich bei CAN primär auf den Zusammenhang der Laufzeiten bei der Busarbitrierung. Da wärend einer Bitzeit das Signal bis zum Ende des Busses laufen muß, dort erkannt und verarbeitet werden muß und dann wieder zurück läuft, darf die Baudrate nicht größer werden, als dieses Prinzip eben zuläßt. Abgesehen davon sind Leitunglängen auch von dem Leitungwiderstand und HF-Eigenschaften (Induktivität und Kapazität) anhängig. Bei einer typ. Signalleitung mit 0,25mm² Querschnitt hat man schon ca. 80 Ohm pro km Widerstand. Wenn oben behauptet wird, Leitungen könnten bei niedrigen Baudraten noch viel länger werden, so gilt das nur unter Voraussetzungen, dass die Leitungen ausreichden hohen Querschnitt haben. Bei 6,7km Länge mit 80 Ohm/km kommen auf der Hin- und Rückleitung schon über 1kOhm Leitungwiderstand zusammen. Bei einem Leitungabschluss mit 120 Ohm am anderen Ende reduziert das den Pegel dann schon auf ca. 1/10 der Sendespannung. Das reduziert den Störabstand schon deutlich und wenn der Pegel noch geringer wird, kann er nicht mehr sicher detektiert werden. Diese Grundaussagen gelten (außer der Busarbitrierung) nicht nur für CAN, sondern im Prinzip auch für andere Bus-Systeme (z.B. RS485). Deshalb rate ich auch jedem Bastler, der irgendwo RS485 verwenden will, moderate Baudraten bis max. 250 kBuad zu nutzen und bandbreitenbegrenzte Treiber zu einzusetzen (z.B. MAX483 statt MAX485) https://datasheets.maximintegrated.com/en/ds/MAX1487-MAX491.pdf. Gruß Öletronika
Hallo, der Beschreibung meines Vorredners zu Stichleitungen und Gesamtlängen kann ich nichts mehr hinzufügen ;-). Die Quelle für die Tabelle hatte ich schnell gegoogelt, und da sie sich mit meiner Erinnerung deckte, hier angegeben. Das Original findet sich unter https://gemac-fieldbus.com/de/leitungslaengen-stichleitungen/ Schöne Grüße, Martin
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.