Hi zusammen
Ich bitte um eure Meinung zu dem folgenden Thema: Ich habe im Haus eine
Ethernet Verkabelung und würde gerne an einigen Stellen Komponenten für
die Automatisierung des Hauses installieren.
Für eine Hausbuslösung gibts einige Ansätze mit CAN, I2C, usw. und auch
Implementierungen dafür. Da ich aber meine bestehende Verkabelung für
meinen Hausbus verwenden möchte, wäre eine weitere Möglichkeit, Ethernet
als Basis zu verweden.
Als Aktoren (Steuerung, Messpunkte, Schalter, usw. ) soll vom uP bis PC
reichen.
Die Kommunikation soll nicht via IP sondern als eigenes Protokoll
aufgebaut werden. Als Vorbild soll der Ethercat Bus dienen, der aber für
die Lösung etwas overkill wäre, da er erstens sehr schnell und beinahe
Echtzeit hinbringt (was ja egal wäre) aber dadurch schnelle Komponenten
und einen aufwändigen Kommunikationsstack benötigt, welcher nicht mehr
einfach auf einen AVR mit z.B. einem ENC28J60 zu implementieren wäre.
Klar, der Nachteil, dass der Bus nicht über einen Router in ander
Subnetze geroutet werden kann, ist nicht so tragisch. Als Erweiterung
könnte man die Ethernet Packete ja in IP Pakete packen.
Hat jemand von euch schon mal mit dem Gedanken eines solchen Buses
gespielt oder schon mal was umgesetzt ?
Grüsse
also nur die kabel, was drüber geht ist dir völlig egal ? also can,
rs485 etc ?
ist eigentlich ganz normal das so zu machen, da cat7 relativ billig
ist...
ich würde dir wenn zu CAN raten, wenn du es selber machen willst, ist am
wenigsten arbeit
Nicht ganz.Die Leitungen werden auch von den "normalen" PC's und NAS
usw. verwendet.
Ich kenne CAN nicht, aber das Protokoll müsste schon innerhalb des
Ethernet Standards sein um die weiteren Kommunikationen (TCP/IP usw.)
über die Kabel nicht einzuschränken.
Ich verstehe Gast(Gast) so, das Ethernet-Pakete gleichzeitig mit IP auf
der existierenden Verkabelung laufen sollen.
Kann man natürlich mit eigenem Frame machen, allerdings ist UDP/IP so
klein, daß man problemlos mit einem Atmega8 arbeiten kann, behält aber
Vorteile wie Routing, einfachen Zugriff über Sockets bzw. existierende
Bilbliotheken etc.
Einen Geschwindigkeitsvorteil hast Du mit eigenem Frame gegenüber UDP/IP
nicht (wenn man mal von den ARP-Requests absieht, aber die kann mann ja
lange genug cachen).
Anfangen kannst Du mit Adam Dunkels uIP-Stack (oder der Inkarnation von
Ulrich Radig), aus dem Du das TCP-Zeug einfach rausschmeißt.
Ich hab auch irgendwo einen UDP-only Stack für AVR gesehen.
ah ok jetzt versteh ich endlich was du willst,
dann stimm ich Sense mal zu, nimm UDP oder lass TCP/IP ein avr kommt da
locker mit klar und für steuerungsaufgaben ist der auch wirklich schnell
genug. das problem bei ethernet ist nur der stromverbrauch wieso ich das
zB @home nicht für sensoren etc verwende ^^
Danke euch für euren Input.
Ich habe die Spezifikation vom EtherCat Bus gelesen und die sagen, dass
der Controller wenn ein Packet vorbei kommt, das Paket ausliest und mit
den eigenen (Prozess)Daten ergänzt und weiter sendet. Das würde
bedeuten, das Packet geht einmal vom Master in die Runde und kommt
zurück, angereichert mit allen Statis der Slaves. Wenn ich auf sowas
schielen würde, ginge ja IP nicht da IP ausser beim Broadcast (wenns das
gibt?) immer Peer-To-Peer macht.
Aber das mit der Anreicherung der Daten verstehe ich nicht ganz. Bei
einer Ringschaltung der Komponenten könnte ich das ja noch verstehen,
aber bei einer Sterntopologie empfängt ja jeder alles. Es kann ja nicht
sein, dass der Controller seine Infos ans Paket hängt, da die Paketinfos
wie Länge im Header sind. Und der ja am Anfang steht.
Habt ihr da ne Idee ?
ethercat ist logisch ein Ring...
Der master sendet ein paket los (ziel ist er selber), dieses Paket läuft
durch alle frames durch, der letzte sendet es wieder durch alle andern
zurück.
switche und sowas machen bei ethercat einfach keinen spass, auch andere
geräte mittendrin sind unschön.
Der vorteil ist natürlich das die teilnehmer kein MAC und IP brauchen.
-----
Für dich wäre "normales" IP mit UDP am besten geeignet, jeder Teilnehmer
ist anhand der kombi eindeutig zu erkennen, der master klappert einfach
alle nacheinander ab und fertig...
Wenn du unbedingt willst kannst du noch die IP weglassen, und mit RAW
Sockets arbeiten, nur das macht auf dem Master (wohl ein PC) kein
spass...
PS: stromsparend ist was anderes...
Aha. Wenn ich ein Sniffer in die Leitung hängen würde, sähe der
folgendes:
Der Master sendet ein Paket an sich selber.
Der erste Slave sendet das befüllte Paket an den Master.
Der zweite Slave sendet das befüllte Paket an den Master.
... usw. bis alle Slaves durch sind.
Wenn das so wäre, bringt das ja nicht so viel. Das Ethercat Paket geht
einmal um den von docean beschriebenen logischen Ring und wird
angereichert.
Hier habe ich die Info her:
http://www.ethercat.org/pdf/german/EtherCAT_Implementierung.pdf
Nun, ich möchte ja nicht Ethercat nachbauen, aber aus Interesse wüsste
ich schon gerne wie das Protokoll die Daten befüllt und mit einem
minimalen Kommunikationsaufwand versendet.
Noch eine weitere Frage:
Was ich nicht ganz verstehe ist der angesprochene hohe Stromverbrauch
von Ethernet.
Danke und Grüsse
Was für ein Netzwerk hast du? Wenn es dir reicht das die PCs mit 100MBit
laufen hat man noch 4 Adern im Cat Kabel frei, darüber kann man dann was
anderes laufen lassen, wird Teilweise bei Telefonen oder ISDN Endgeräten
so gemacht. Gibt zwar leichte Störungen auf die Kabel bei Cat 5 sollte
das Netzwerk aber nicht wirklich beinträchtigen. Damit könnte man auch
einen Echtzeitbus hin bekommen. Muss man dann vor jedem Aktiven Gerät
die Kabel sotieren. Der Bus sollte dann min gegen ca. 50V auf den Adern
gesichert sein falls doch mal eine Aktive Komponente mit auf den Bus
geraten sollte.
Geht leider bei 1.000 MBit Netzwerken nicht mehr da dort alle Adern mit
eine Frequenz von ca 67MHz belegt sind. Wenn man darauf andere Daten
Senden möchte muss man die Freqenz erhöhen (bei Cat 5 max 100MHz), die
ganzen Ethernetdaten Empfangen und in den Bus jagen und dann noch seine
Eigenen Daten mit drauf packen und diese auch versenden, dürfte im
Hobbybereich jedoch aus kostengründen ausfallen. Auf der Empfängerseite
muss man das natürlich wieder auseinander klamösern. Meistens ist es
jedoch billiger einfach ein neues Kabel einzuziehen.
Das Problem bei dem Stromverbrauch über Ethernet ist das immer
Komponenten an sind wie, Switchen, Hubs, Router und die Ganzen
Busteilnehmer brauchen pro Stück ca. 200mA mehr als mit herkömlichen
Bussen. Was man machen könnte ist einen Ethernetteilnehmer pro Raum und
von dort aus auf einen Anderen Bus wechseln was jedoch wieder eine
gewisse Verkabelung vorraussetzt. So ähnlich habe ich es bei mir zur
Zeit gelösst.
>Nun, ich möchte ja nicht Ethercat nachbauen, aber aus Interesse wüsste>ich schon gerne wie das Protokoll die Daten befüllt und mit einem>minimalen Kommunikationsaufwand versendet.
Eine Menge Infos findet man auch auf
http://www.beckhoff.de/default.asp?ethercat/default.htm ("Erfinder" von
Ethercat)
---------------------------
Pakete = Züge
Teilnehmer = Bahnhöfe
Leitungen = Schienen
Normales Ethernet verschickt zu jedem Teilnehmer eine Zug (ein Paket),
der läuft in den Bahnhof ein, es wird ein- und ausgeladen, und dann wird
der Zug wieder zurückgeschickt. Das dauert alles zeit und belastet die
Schienen, auch wenn nur 2 Bit abzuholen sind.
Ethercat schickt einen Zug los, dieser kommt bei jedem Teilnehmer
vorbei. Der letzte Teilnehmer hat eine Umkehrschleife und schickt das
Paket dadurch zurück (gleicher Weg wie hin). -> Nur ein Zug unterwegs
Der zu hält in den Bahnhöfen nicht an!! sondern die "Waren" werden im
vorbeifahren also ohne den Zug abzubremsen ein- und ausgeladen.
-> Kein Geschwindigkeitsverlust
------------
Zum Stromverbrauch -> Schnelle Technologie -> mehr Stromverbrauch
Dein PC von heute brauch auch mehr Strom als einer vor x Jahren
das mit der geschwindigkeit von ethercat ist bei einem hausbus aber eher
"theoretisch" und wohl erste beim >= 1000 eingängen (bei denen sich die
werte/zustände schnell ändern) wichtig...
Hast du dir mal Powerlink angesehen? Anders als bei EtherCAT werden
dafür keine (speziellen) ASICs/FPGAs benötigt - es können "normale"
Ethernet-Komponenten verwendet werden. Die Technologie ist offen
(zumindest offener als EtherCAT) und die Sourcen dazu gibt's bei SF
(openPowerlink)... Evtl. wäre das ja ein Ansatz.
>Was ich nicht verstehe, ist das beschriebene Waren hinzuladen, wie es>unter 1.2 in dem folgenden Dokument beschrieben wird.
Die Daten werden "on-the-fly" gelesen und geschrieben - weswegen auch
ESC (EtherCAT Slave Controller) in Form von ASICs oder FPGAs nötig sind.
"on-the-fly" heißt der Anfang des Frames wurde bereits zum nächsten
Slave gesendet, während das Ende des Frames noch empfangen wird...
jeder Teilnehmer weiß an welche Stelle des Frames er seine Daten
schreiben/lesen soll
Nehmen wir mal an ein Teilnehmer ist ein Ausgang (1 Bit), dann kommt der
Frame angeflogen und der Teilnehmer fängt an die Bits zu zählen und
sendet gleichzeitig die Bits wieder an seinen Ausgang.
Wenn jetzt die Stelle mit seinen Daten kommt (dem einem Bit) wird dieser
Wert nicht nur weitergesendet sondern auch der Ausgang auf den passenden
Wert gesetzt.
Sorry für die Rückfrage: was ich nicht verstehe ist, das Weitersenden.
Das funktioniert aber nur, wenn der erste Slave die Daten empfängt, die
Daten an einen weiteren Slave oder den Master sendet. Dies bedeutet, die
Daten gehen bei allen Slaves vorbei und jeder Slave muss genau wissen zu
welchen nächsten Slave die Daten gehen sollen. Also nicht in einem
Broad- oder Multicast Mode.
Wenn ich die Kommunikation "Sniffe", sehe ich bei einer Topologie von 1
Master und 3 Slaves 4 mal das Datenpaket auf dem Kabel.
Wenn der Master jeden einzelen Anspricht, wie bei Powerlink, bräuchte es
einige mehr, der Master würde aber mittels Timeout einen SlaveAusfall
bemerken.
Bei der ersten Variante müsste der Slave dem Master mitteilen, dass ein
Slave nicht antwortet und dieser dem Slave den neuen Zielslave mitteilen
oder den Datenverkehr neu anstossen.
