100 AVRs miteinander verbinden

[shaun]

RS485 kann weitaus mehr Teilnehmer als 32, wenn man aktuelle Transceiverbausteine mit niedrigem Fan-In benutzt. Die logische Grenze liegt sowieso in der Phantasie des Programmierers.
Wenn die Erstellung eines simplen Protokolls für einen Halbduplex-Bus zu hoch ist, wirst Du mit CAN-fähigen Controllern auch nicht glücklich, CAN bedeutet nicht, dass der Controller einem alles abnimmt, sondern dass er die Hardware mitbringt, für die man dann die Software schreiben darf.
Ich wäre auch für RS485, weil die Bausteine günstig, das System erprobt und die Übertragung überschaubar bleibt. Komplexere Standards wie CAN, LIN usw bieten zwar mehr, aber fordern auch mehr bei der Implementierung.

[Benji]

Wäre es möglich über Netzwerkkabel zu kommunizieren (Ethernet?)

Eventuell wäre es sinnvoll, das ganze mit einem normalen Ethernet zu machen.

Ich würde auch diese Variante bevorzugen. Habe gemerkt das diese einen grossen Vorteil bei der Fehlersuche haben gegenüber den andern Protokollen (CAN, RS485). Wenn bei der Inbetriebnahme etwas nicht funktioniert kann bei Ethernet die Verbindung per Ping prüfen.
Bei den anderen Bussen ist es meist aufwändiger die Verbindung zu testen. Da können noch lange alle LEDs auf grün sein, wenn es trotzdem nicht funzt
Also ist mein Favorit Ethernet. Das hat sich (bis jetz ) bewährt.

[pongi]

Hallo!

Es ist Schwachsinn, dass man bei RS485 nur 32 Teilnehmer haben kann. Wenn du ein Adressbyte (8Bit) für die Adressierung nimmst, hast du gleich 256 Slaves... Bei uns in der Firma arbeiten wir auch mit sowas, die Monitoring Software habe ich selber geschrieben, und wir haben weit mehr als 100 Messstellen.
Vorteile: UART ist in jedem AVR implementiert, und mit einem passenden MAX*** Pegelwandler hat sich das Problem erledigt. Auch beim Rechner ist es am einfachsten den COM-Port auszulesen.
Nachteile: wenn du die Sensoren selber baust (oder zumindest die AVRs selber dranhängst), musst du selber für dich ein Protokoll entferfen. Das kann aber abhängig von deinem programmiertechnischen Wissen auch ein Vorteil sein.
Beispiel für ein einfaches Protokoll:
Festgelegte Bytelänge von X Bytes=1Byte Adresse+y Byte Daten+z Byte Kontrolldaten
Wenn AVR seine Adresse am Bus hört, schickt er die Daten und die evtl. Checksums. Die anderen Wissen anhand der Datenmenge, wann sie wieder zuhören sollen, um ihre Adresse zu erwischen.

MfG

pongi

[E-Fan]

@pongi:
Das ist kein Schwachsinn mit der Begrenzung auf 32 Teilnehmer sondern hat einen ganz einfachen Grund:
Der Gesamtwiderstand den die Empfänger zusammen haben sinkt bei zunehmender Teilnehmeranzahl irgendwann so weit ab das der Pegel auf den Leitungen nicht mehr ausreicht um die Zustände zu detektieren die Übertragen werden sollen.
Um dem entgegenzuwirken muss man einen Repeater in die Leitung hängen (nen Leitungstreiber mit Schmitt-Trigger reicht da prinzipiell aus) um zum einen die Teilnehmeranzahl und zum anderen die maximale Leitungslänge zu erhöhen.
Insofern hättest Du mit Wissen statt Halbwissen auf Deine Wortwahl verzichtet wenn Dir der RS485-Standard, dessen Aufbau und Funktionsweise bekannt gewesen wäre.
WAS mittels RS485 übertragen werden kann ist ein völlig anderer Schuh. Das ist nämlich Protokollabhängig.

Vom Ethernet würde ich versuchen die Finger zu lassen. Das Übertragungsprotokoll ist an sich schon sehr aufwändig und dazu kommen die murkeligen Westernstecker die kaum einer mechanischen Beanspruchung standhalten können.

[Hessibaby]

Wir machen Kraftwerksleittechnik, da wird mit gemischten Topologien gearbeitet. An einer Maschine RS485, das geht auf einen OPC-Server mit Ethernetanschluß (BNC-Ring) und dann auf die Prozessrechner bzw. Visualisierungssysteme. Natürlich ist alles (aus Sicherheitsgründen) redundant ausgeführt. Zwischen den Gebäuden liegt, um Potentialverschleppungen zu vermeiden, Glasfaserkabel.
Gruß

[shaun]

@Fragesteller: und wo kommt das Ethernet her, wächst das am Baum? Bis Du das funktionsfähig auf einem AVR implementiert hast, steht das RS485-Netz und ist ob seiner Einfachheit notfalls mit RS485/RS232-Wandler mit dem Schleppi überall überwachbar. Dein Ethernet hingegen musst Du Dir erstmal vier Schichten ISO/OSI aus den Fingern saugen, vorher pingt da gar nichts. Dass Du meinst, im Ethernet pingen zu können, spricht umso mehr dafür, ein überschaubares Bussystem zu verwenden.
(Für die, die jetzt auch kleinlich werden: für einen ARP-Ping bräuchte man sich nur um drei Schichten Gedanken machen)

[Benji]

@shaun
Das war nicht der Fragesteller, sondern ich. Aber dafür brauchst du dich nicht so aufzuführen. Ich habe mit Ethernet bisher gute Erfahrungen gemacht. Auch RS485 kann man nicht pflanzen und warten bis man es vom Baum pflücken kann.

[pongi]

Ich entschuldige mich hiermit bei allen, die sich durch das Wort Schwachsinn beleidigt fühlen...

Es ist aber trotzdem möglich, mehr als 32 Teilnehmer am RS485 zu betreiben, wie gesagt bei uns sinds mehr als hundert. Die modernen Treiberbausteine arbeiten mit 1/8 des UnitLoads, die bei RS485 spezifiziert ist, deshalb sind auch 256 Teilnehmer möglich. Sicher ist das auch von der Umgebung und dessen Störungen abhängig, es geht aber bis zu einer gewissen Grenze auf alle Fälle.

[shaun]

@Benji: sorry, Missverständnis. Ich war der Meinung, der Fragesteller, dem es eingangs bereits als zu viel verlangt erschien, ein Protokoll zur Halbduplexkommunikation per RS485 zu erstellen, wollte nun mal eben einen TCP/IP-Stack auf einem AVR stricken. Da lag für mich ein indiskutabler Widerspruch - unberechtigter Weise, da Du ja gar nicht TKCUBA bist.

Oder würdest jemandem, der kein Protokoll für eine serielle Kommunikation auf unterstem Niveau schreiben kann oder mag, ernsthaft empfehlen wollen, es mal mit Ethernet und TCP/IP zu versuchen?
Klar, es gibt bereits benutzbare Ansätze, aber auch die werden nicht auf Anhieb das tun was sie sollen, und wie soll der arme Mensch darin einen Fehler finden oder eine Anpassung vornehmen?

[Benji]

@Benji: sorry, Missverständnis. Ich war der Meinung, der Fragesteller, dem es eingangs bereits als zu viel verlangt erschien, ein Protokoll zur Halbduplexkommunikation per RS485 zu erstellen, wollte nun mal eben einen TCP/IP-Stack auf einem AVR stricken. Da lag für mich ein indiskutabler Widerspruch - unberechtigter Weise, da Du ja gar nicht TKCUBA bist.

Ok schon vergessen und gefressen

Oder würdest jemandem, der kein Protokoll für eine serielle Kommunikation auf unterstem Niveau schreiben kann oder mag, ernsthaft empfehlen wollen, es mal mit Ethernet und TCP/IP zu versuchen?
Klar, es gibt bereits benutzbare Ansätze, aber auch die werden nicht auf Anhieb das tun was sie sollen, und wie soll der arme Mensch darin einen Fehler finden oder eine Anpassung vornehmen?

Nun ja, da könntest du Recht haben .

Wäre eine Steureung über SPS auch eine Lösung? Dort wäre die Implantation dann nicht mehr ein grosses Problem...