Also ich habe meine Hausinstallation Sternförmig aufgebaut mit einigen
Unterverteilern. Nun suche ich eine Relativ günstige möglichkeit die
ganzen Verbraucher zu Schalten.
Meine überlegung ist ich nehme einen PC der alles steuert.
Auf diesen PC kann ich mit Clints (Xbox mit Linux) über VNC zugreifen.
Auf dem Master PC läuft eine Delphi Software welche für die
Comunikation mit der RS232 Schnittstelle entscheidet.
Nun will ich sagen wir mal 100 oder mehr µCs an diese Schnittstelle
hängen und diese sollen auf bestimmte Adressen reagieren und die
Aktoren schalten. (Ok eigentlich ist der µC der Aktor)
Nun meine Frage macht das dem Signal was aus wenn es an mehreren µCs
angeschlossen ist oder nicht?
Als Verbindungsleitung vom PC zu den µCs ist Cat5e verlegt worden.
Wie könnte ich es hin bekommen das die µCs auch noch untereinander
kommunizieren könnten?
Dazu dachte ich mir das ich Gruppen in Schaltschränken über einen
eigenen Bus zusammenführe (Parrallel Port an Port)
So in dieser richtung sähe das Netzwerk dann aus.
[]µC
* Sternpunkt
[PC]PC
[PC]----*---[]---[]---[]---[]
| |
| |
[]---[]---[] []---[]---[]
Natürlich mit viel mehr µCs.
Für die µCs wollte ich welche von Atmel verwenden.
das ist kein Problem des MC, sondern der Schnittstellenbausteine. Bei üblichen RS232 musst du sicher mit der Baudrate runtergehen, je nach Gesamtleitungslänge. Wieviele Eingänge ein Treiber verkraftet, kann ich dir jetzt auch nicht sagen, logisch ist das jedenfalls kein Problem. Ohne Rückkanal wird das Ganze aber mit Sicherheit schiefgehen. Du schickst eine Meldung los und hoffst, dass sie ankommt. Was, wenn nicht? Merkst du nicht einmal. Ich würde RS485 nehmen und alles quittieren lassen. Mit einer einfachen 2Drahtleitung hast du bidirektionalen Verkehr, zwar nur Halbduplex, aber das ist kein Problem.
Nein mom ich habe da noch was vergessen... Ich jage das hinter dem PC durch einen MAX232 oder 202 durch und bekomme dann das 5V Signal. Dieses schicke ich direckt auf den µC und zwar auf alle gleichzeitig. An Rx und Tx und werte die Daten dann aus. Einen rückkannal habe ich dadurch doch. Ich habe ja einmal Rx zum Senden und Tx zum empfangen, oder andersrum, ich vergesse das immer weider... Dann lege ich alle Rx und Tx von den kompletten µCs an den Bus und muss denen nur noch sagen macht mir keine Kollisonen im Netz. Getestet habe ich das ganze bisher mit zwei µCs im Betrieb ohne lange kabelverbindung das ging ja wunderbar, aber ich denke mir irgendwann ist das Signal duch die vielen Eingangswiederstände der vielen µCs so fertig das sie das Signal nicht mehr erkennen können.
Angehängte Dateien:
-
mctest.jpg
87 KB
so wie auf dem anhängenden Schaltplan habe ich mir das vorgestellt.
Die Txe hängen jetzt aber alle an einer Leitung soll heißen da kanns sehr leicht passieren das mehrer Ausgänge gegeneinander treiben. Selbst wenn du den Tx auf Eingang lässt und nur auf Ausgang schaltest, wenn er senden soll kann es bei 100 µCs sehr schnell durch was auch immer für Umstände dazu kommen das zweie gleichzeitig senden... Also ich würde auf jeden Fall Schnittstellen-ICs verbauen. Abgesehen von der Kollisionsproblematik könnte auch der 5V-Pegel bei der Leitungslänge zum Problem werden.
Das funktioniert so nicht. Setze einen MAX483 auf der PC-Seite und pro MC ebenfalls einen. Damit kannst Du bis zu 256 Geräte am Bus betreiben. Die RS485 ist zwar eigentlich nicht für sternförmige Verbindungen gedacht, funktioniert aber bei einigen mir bekannten Installationen (max. 200m Leitungslänge, 9600 Baud [nein, die sind nicht von mir]) recht gut. Steffen
Nimm statt RS485 RS422 - das ist die für diese Anwendung vorgesehene Treibertechnik. Damit lassen sich problemlos mehrere hundert Meter Kabel mit hundert Teilnehmern versorgen - sofern man mit der Baudrate in einem sinnvollen Rahmen bleibt; 9600 ist kein Problem. Du wirst Dir allerdings einige Gedanken um ein sinnvolles Kommunikationsprotokoll der µCs mit dem PC ausdenken müssen - ein Master-Slave-Protokoll mit Telegrammen definierter Länge und Pollen der einzelnen Slaves löst Kollisionsprobleme. Wenn es um Hausautomation geht, sind die Antwortzeiten ja nicht so sonderlich kritisch (wer will eine Raumtemperatur binnen 3 ms ändern?). Statt das Rad neu zu erfinden, könntest Du Dich an einem bestehenden Protokoll orientieren; da gibt's ja 'ne ganze Menge. Derlei Verfahren werden in industrieller Gebäudeautomatisierungstechnik eingesetzt und funktionieren dort ohne Probleme.
Also ich hab mir jetzt mal alle möglichen übertragungsarten angeschaut und finde das can protokoll am interesantesten. Ich habe auch schon viel hier im Forum zum lesen gefunden und ein wennig danach gegoogelt. Leider habe ich eine grundlegende sache noch nicht verstanden... Also ich Programmiere meine Atmels, welcher ist mir eigentlich für dieses projekt egal, in Asambler. Wenn ich jetzt einen belibigen Atmel nehme und diesen mit dem MCP 2515 verbinde (parallel?) kann ich dann einfach ein byte an den MCP2515 schicken und der gibt das auf dem canbus aus? warscheinlich nicht das währe bestimmt zu einfach. Vieleicht würde mir ein beistpielqueltext mit kommentaren helfen, leider habe ich noch keinen brauchbaren gefunden.
der mcp2515 wird per spi angeschlossen, sollte also schon ein avr sein, der das in hardware hat. ganz so einfach geht die ansteuerung leider nicht, sonst wäre das datenblatt nicht 80 seiten stark :) http://ww1.microchip.com/downloads/en/DeviceDoc/21801b.pdf
@Matthias Schau Dir doch mal diese Seite an: i2c rs485 Adapter http://vodka.tky.hut.fi/~jap/Electronics/I2C-adapter/index.html Und allgemein: http://zebra.tky.hut.fi/~jap/Electronics/ Könnte für diese Aufgaben eine Alternative zum CAN Bus sein. Stellt quasi einen verlängerten I2C Bus dar. Ich hab für mein nächstes projekt ( sowas wie eine Alarmanlage ) mich für diese Variante entschieden. Kann aber noch nicht sagen obs funktioniert Die Hardware ist noch im Bau. Ich meine das bietet einige Vorteile. Hardware kosten praktisch null. i2c ist in den Megas per Hardware ansprechbar. Sternförmiger RS485 Verkabelung ist über die i2c kopplung möglich. Nicht alle Busteilnehmer müssen mit einem uC ausgestattet sein- I2C Bauteile können einfach so an den Bus gekoppelt werden. Das i2c protokoll ist einfach und Librarys sind verfügbar.
"kann ich dann einfach ein byte an den MCP2515 schicken und der gibt das auf dem canbus aus?" Im Prinzip schon, allerdings ist das nicht sinnvoll. Es sollte schon der Empfänger erkennen können, daß das Byte für ihn bestimmt ist. Deshalb gehört noch ein Identifier (= Adresse) dazu. Und oft reicht ein Byte nicht aus, deshalb kann man die Pakete von 0 ... 8 Byte schnüren. Aber um mehr brauchst Du Dich nicht zu kümmern (Fehlererkennung, Wiederholen bei Fehler, Kollisionserkennung, Empfangsquittung), das macht alles der Chip für Dich. Im Gegensatz zu RS-485, wo Du diesen ganzen Protokollschrunz umständlich zu Fuß machen mußt. Deshalb würde ich für Neuentwicklungen von RS-485 dringend abraten (warum sich das Leben nur unnütz schwer machen). Peter
Könnt ihr mir vieleicht auch noch helfen etwas zu finden. Ich brauche im endefeckt zwei Knoten und eine RS232 Anbindung für den PC. Vieleicht noch ein PC Programm was dann die Daten auf dem Bus Logt. Möglichst so das ich nur noch die Platinen ätzen muss und die Bauteile anlöten. Dann könnte ich anhand dieser relativ einfachen schaltung bestimmt ganz leicht erkennen wie das ganze funktioniert. Leider habe ich bisher nur recht komplizierte Schaltungen gefunden mit jeder menge Schnickschnackt... Habe ich das auch richtig verstanden das man über den Can bus die Atmels Programmieren kann, also grob ausgedrückt ich schicke das kompilierte *.hex file über den RS232 Anbinder in den CanBus, mit zieladresse natürlich, und der rest ist schon alles fertig?
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.