100 AVRs miteinander verbinden

Hey Leute!
Ich muss eine Lösung für folgendes Problem finden.

Etwa 100 Geräte
Die in Schränken über eine Werkshalle verteilt sind, sollen überwacht werden und die Informationen in ein Büro an einem einzelnen PC ausgegeben werden.

Die Daten bestehen aus Temperatur, Spannungsmessung, Spannungssteuerung und andere PIO Signale.

Mein Gedanke:

Die Steuerung am PC erfolgt über eine VB6 Anwendung.

Ich dachte jedes Gerät bekommt einen AVR. Damit sind die Mess, Regel und Steueraufgaben schon einmal abgehackt.

Die schließe ich über ein Bus System an den PC an.
Master/Slave Prinzip.
Die 100 Geräte als Slave und der PC bekommt ein Steuergerät (Master) das über USB mit der Windows-Anwendung verbunden ist.

Das Hauptproblem ist das Richtige Bussystem für so viele Slaves zufinden, das auch noch eine gewisse Leiterlänge zuläst.

Hat irgend jemand eine Idee was ich für einen Bus nehmen könnte?

Vielleicht I2C zusammen mit einem Extender,
dann soll I2C auch für größer Entfernungen gehen.


Sollte jemand Ideen, Anregungen, Fragen oder Besserungsvorschläge haben. Bitt,e bin für alles offen.

MfG
TK

Hi, schau dir mal den CAN-Bus an.
Es gibt auch einen AVR mit CAN-Interface.
Der CAN-Bus bietet dir sehr komfortable und vor allem sichere Kommunikation relativ leicht an. 100 Slaves sind kein Problem.
I²C über diese Entfernungen geht nicht.
Die Alternative wäre ein selbstgestricktes Protokoll auf RS-485-Basis. Das dürfte aber mehr Arbeit machen.

Sigo



Sigo

Hi

Von der Menge her könnte man I2C nehmen, aber die Länge würde da wahrscheinlich ein Problem machen. Ich glaube dort kann darf man die Leitungen nicht länger als 9m ziehen (mit Extender 50m)

Für grosse Distanzen eignet sich RS485. Dort macht die Teilnehmerzahl Probleme (max 32)

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

edit:
Bei Ethernet: Jeder Teilnehmer hat seine IP und per Ping kann die Kommunikation getestet werden...

ich würde jedem gerät einen rs485 treiber spendieren und den bus auf rs485 basis aufbauen laut norm geht da bis 500m... es gibt verschiedene treiber die je nachdem mehr oder weniger geräte am bus zulassen...
musst du dir halt einfach ein protokoll überlegen damit du die geräte nacheinander abfragen kannst...

gruss bluesmash

Hi!
Du kannst auch irgendein Protokoll in Verbindung mit LichtwellenleiterInterfaces benutzen. Dann ist die Länge nur durch das LWLSystem begrenzt. Dazu benötigst Du natürlich zusätzliche Hardware. Dafür ist es aber auch unempfindlich gegenüber elektromagnetischen Störungen.
Grguß

sind lichtleiter bei einem solchen system nicht ein wenig übertrieben ;)
rs485 wird in der industrie seit jahren erfolgreich eingesetzt, und mit einem gut abgeschirmen kabel ist man auch relativ unempfindlich gegen störeinflüsse....

gruss bluesmash

Ich habe irgend wo einen text überflogen in dem stand das der RS487 bis zu 128 teilnehmer zulässt. Wo der hacken ist weiss ich noch nicht.

Ist eh egal ich fürchte ein eigenes Übertragungsprotokoll liegt über meinem Wissen. Denn ich habe keine Ahnung wie so etwas aussehen muss.

Ich würde wie sigo zu CAN raten. Große Leitungslängen sind kein Problem und die Anzahl der Knoten ist auch nicht begrenzt, wenn ich mich nicht irre. Störsicher ist CAN durch zwei differentielle Leitungen auch.
Zudem ist CAN ein Multi-Master System, Du könntest also auch noch irgendwo problemlos einen zweiten Auswerte-Rechner dranhängen, wenn das mal gewünscht sein sollte.

askazo

Bluesmash schrieb:

Zitat:

---

sind lichtleiter bei einem solchen system nicht ein wenig übertrieben

---

Wer genau hinliest wird feststellen, dass Ideen und Anregungen gefragt sind. Dies ist eine. RS485 hingegen ist keine, weil sie nur 32 Teilnehmer unterstützt. Außerdem ist es nicht unbedingt ein Leichtes, RS485 auf nem Mega zu implementieren.
CAN in einem Atmel gibt es schon. CAN ist empfehlenswert.
Von RS487 würde ich die Finger lassen. Das ist sehr speziell weshalb es keine Erfahrungen gibt (vor alem mit der Hardware)
Gruß

Hallo,

als erstes würde ich die folgenden beiden Fragen klären:
1. Welche Übertragungsrate wird benötigt?
2. Was ist die beste Topologie? Möglich wäre sowohl eine Sternförmige Verkabelung (Von jedem Teilnehmer geht ein Kabel zu einem zentralen Steuergerät) oder ein einziger grosser Bus, an dem alle Teilnehmer parallel angeschlossen sind (wie z.B. I2C). Beide Ansätze haben natürlich ihre Vorteile und Nachteile (Fehleranfälligkeit, Übertragungsrate, Verkabelungsaufwand etc.)

Eventuell wäre es sinnvoll, das ganze mit einem normalen Ethernet zu machen. Das hat den Vorteil, dass man für den Master lediglich einen normalen, netzwerkfähigen Computer benötigt. Für die Verteilung kann man relativ billig fertige Switches kaufen. Man muss also ausser den Platinen mit den Controllern keine eigene Hardware entwickeln. Ausserdem sind viele Werkzeuge zur Diagnose bei Problemen frei verfügbar (z.B. ping, Sniffer). Das Protokoll könnte man relativ einfach über UDP machen. Der Master schickt dann in regelmässigen Abständen eine Anfrage an alle Slaves und diese antworten darauf mit aktuellen Sensorwerten. Zum Anschluss des µC an das Netzwerk könnte man z.B. einen ENC28J60 verwenden. Eventuell könnte man den Verkabelungsaufwand weiter reduzieren, indem man die Sensoren einfach an ein vorhandenes Netzwerk anschliesst.

Gruss
Jakob

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.

Zitat:

---

Zitat von Benji

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

---

Zitat:

---

Zitat von Jakob L.

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.

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

@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.

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ß

@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)

@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.

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.

@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?

Zitat:

---

Zitat von 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.

---

Ok schon vergessen und gefressen ;)

Zitat:

---

Zitat von shaun

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...

@benji: <Erleichtertsei> O:)

Ich muss ganz ehrlich sagen, dass ich, als ich letztes Mal eine Netzwerkanbindung für ein Messgerät durchführen sollte, einen XPort benutzt habe. Das Ganze hat eh schon den Umfang einer normalen Studienarbeit bei weitem gesprengt, da wollte ich nicht gleich noch eine "Doktorarbeit" drauflegen und einen TCP/IP-Stack programmieren. Nur sind die XPorts nicht so preiswert, dass ich sie ernsthaft als Alternative zu RS485 für die genannte Anwendung in Betracht ziehen würde. Wobei Ethernet natürlich den Vorteil einer galvanischen Trennung hätte, bei Industrieautomatisierung nicht zu verachten.
Was die SPSen angeht: ich habe so das Gefühl, dass es gerade um etwas sps-ähnliches geht, was da zentralisiert überwacht werden soll...

@pongi:

Von Beleidigung ist hier nirgends die Rede. Die Wortwahl war halt nicht so passend und das ursprüngliche RS485-Protokoll sieht nun mal nicht mehr als 32 Teilnehmer auf einer (einfach ausgeführten) Leitung nicht vor, was aber nicht bedeutet das man nur 32 Adressen zur Verfügung hat.
Das auf RS485 basierende DMX-Protokoll bietet in der Spezifizierung von 1990 immerhin 512 Adressen die sich auf bis zu 32 Teilnehmer verteilen dürfen und erlaubt maximal 1km Leitungslänge.

An den 32 Teilnehmern beim RS-485 würde ich mich nicht stoßen, es gibt modernere Treiber, die bis zu 256 Teilnehmer treiben können..

Aber dennnoch würde ich CAN den Vorzug geben, da:

Protokoll bis Layer 2 in Hardware und sehr störsicher
fertige Datenobjekte bis zu 8 Byte Nutzlast
11 bzw 29 Bit Identifiert, also Teilnehmer - Adresse satt
Multimasterprotokoll
Eine Kollision führt nicht zu Verlust des Datendurchsatzes

Wenn man CAN - OPEN außen vor lässt, kann man deine Aufgabe auf der Ebene II des Schichtenmodels mit sehr einfachem eigenen Schicht 7 realisieren, das geht ziemlich schnell, da das ja alles in Hardware vorliegt.
Sigo

[quote="shaun
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?
[/quote]

Moin moin,

rs485 klappt ganz gut, ich habe damit schon Schwenk-Neige-Zoom
Kameras über längere Strecken mittels Treiber SN 75176 und
nen Pic angesteuert. Auch mehrere I/E Module mit Pic und einigen
I2C I/E chips waren kein Problem und Leitungslängen bis zu
1000 m gingen auch. Notfalls wurden einfach die Datenleitungen
mittels Pull up und Down (auf beiden Enden) an die Beriebsspannung gehangen. :-) Etwas kritisch haben sich die "üblichen" 120 Ohm
Abschlußwiderstände verhalten, besser mit nen Ozzi und Poti
einen Wert ausmessen bei dem die Flanken der Signale nicht
"verbogen" werden dann läuft der Bus stabiel. :-)

Tcp/ip hat natürlich auch seinen Reiz und wenn man fertige Module
mit Server Chip nimmt sollte das Protokoll auch weniger ein Problem
sein. So etwas hat heute jede web Kamera intern. :-)

Gruß Richard