Hallo, ich habe ein neues Projekt, bei dem ich eine Steuerung für ein Transportmodul erstellen soll. Die gleichartigen Steuerungen der Module sollen sich selbstständig dezentral organisieren und nur mit ihren nachbarn kommunizieren. Das heißt ohne ein übliches Bussystem mit Addressierung, da die Module auch nicht wissen sollen "wo" oder "wer" sie sind und somit keine Adressen zugewiesen bekommen. Da die Module sehr klein sein werden und die Verbindungen zwischen ihnen kaum länger als 20cm werden sollten, überlege ich, ob ich einfach SPI als Basis nehmen kann. Das würde mir ermöglichen die maximal 8 Nachbarmodule mit 8 Select-Leitungen (oder weniger) auszuwählen und die Daten zu übertragen. Um eine zeitgleiche Kommunikation von mehreren Modulen im Gesamtsystem zu ermöglichen, ohne das diese sich gegenseitig behindern müssen die Kommunikationsleitungen voneinander getrennt sein. Das würde ich durch über die Select-Leitungen geschaltete Relais realisieren, die eine Übertragung auf SDO, SDI und CKL nur auf den benötigten Leitungsabschnitten ermöglichen. Ist das Eurer Meinung nach möglich, oder habt ihr andere Ideen/Anregungen? Wie funktioniert SPI als Multimastersystem? Kann ich beispielsweise mit einem ATmega16 solch ein Kommunikationssystem realisieren und wie verhalten sich AVRs wenn ein Konflikt (Mehrfachbelegung) auf dem SPI auftritt? Kann mir jemand Sagen, ob es ICs gibt, die man als SPI/SPI-Transceiver (oder währe Repeater richtiger) verwenden kann, da das dem Verhalten das ich für die Leitungstrennung brauche am ehesten entspricht. Danke im Voraus für die Hilfe. Ich weiß, das ich ziemlich früh mit meinen Fragen zu euch komme, aber ich habe etwas Zeitdruck bei dem Projekt und hätte mich ansonsten auch erstmal 2 weitere Wochen durch Datenblätter und andere Literatur gewühlt. Steffen
Mir ist gerade noche eine einfache Alternative eingefallen, könnte ich auch SPI und I²C einsetzen? SPI als Kommunikation zwischen den Steuerungen und I²C Steuerungsintern. Was haltet Ihr davon? Steffen
Also für ein dezentrales System würde ich weder I2C noch SPI einsetzen, da diese nativ Master-/Slave-Systeme sind. Mein Vorschlag wäre, die Verbindungen untereinander über eine asynchrone serielle Schnittstelle zu machen. Jedes Modul hat dann 8 solcher Schnittstellen (dein vorgegebenes Maximum an Nachbarn), mit denen das Modul kommunizieren kann. So wäre erst mal der Krampf mit wer ist Master/ wer Slave weg, da jedes Modul einfach Daten zum Nachbarn schicken kann (über Datenpuffer sehr gut realisierbar). Viel Spass beim Planen ;-)
> Die gleichartigen Steuerungen der Module >sollen sich selbstständig dezentral organisieren und nur mit ihren >nachbarn kommunizieren. Was sind das für "Module"? Was ist ihre Aufgabe? Sollen das Sensoren sein? Du mußt schon ein wenig konkreter werden. Nur als Beispiel: Wenn die "Module" vom Master(µC) lediglich abgefragt werden sollen, ist die ganze Sache ziemlich einfach.
@Flo: An RS232 haben wir auch schon gedacht, wichtig währe dabei aber eine Realisierung der Schnittstelle mit möglichst wenigen Leitungen. Kann man uCs auch nur über TxD und RxT verbinden? Das währe dann wohl eine recht elegente Lösung. Die Anzahl der Leitungen ist wichtig, da für zukünftige Versionen eine Plug&Play anbindung der Module zueinander angestrebt ist und je mehr Leitungen desto Fehleranfälliger. @Werner Die Module sind gleichberechtigte und gleichartige Teilnehmer am Gesammtsystem aus Modulen. Jedes Modul hat normalerweise eine Steuerung, Aktoren (2 Motoren) und einen Sensor. Jedes Modul kann Senden und Empfangen und besitzt zu seinen Nachbarn (max. 8 Module) je eine Bidirektionale Schnittstelle.
>Die Module sind gleichberechtigte und gleichartige Teilnehmer am >Gesammtsystem aus Modulen. Jedes Modul hat normalerweise eine Steuerung, >Aktoren (2 Motoren) und einen Sensor. Jedes Modul kann Senden und >Empfangen und besitzt zu seinen Nachbarn (max. 8 Module) je eine >Bidirektionale Schnittstelle. >An RS232 haben wir auch schon gedacht Das ist bei den Anforderungen ja wohl ein Scherz? Nimm Ethernet.
Nimm seriell, geht eben auch nur mit rx und tx (und Masse natürlich). Der physical layer wäre dann die serielle asynchrone Übertragung, darauf kannst du ein schönes Protokoll aufsetzen. Btw über was solln sich die Module unterhalten?
@Holger Ethernet ist keine brauchbare Lösung. Die Module sollen nur mit ihren jeweiligen Nachbarn kommunizieren! Diese Kommunikation läuft nicht über einen Globalen Bus/Netzwerk sondern über Bidirektionale Leitungen und sie sollen auch kein eine eigene Identität/Adresse haben, was für so ziemlich jeden Bus eine zwingende Voraussetzung ist. Das alles habe ich oben beschrieben.
> Btw über was solln sich die Module unterhalten?
@Flo
Wie oben angedeutet handelt es sich um Transportmodule, diese können
Objekte (Pakete und so ein Zeug) in jede belibige Richtung bewegen.
Dabei sollen die einzelnen Module selbständig entscheiden wolang sie ein
Paket am besten befördern und wie sie das Ziel am
schnellsten/effektivsten erreichen. Trotzdem sollen die Module
vollkommen austauschbar und das Gesamtsystem jederzeit umstrukturierbar
sein. Natürlich sollen dabei immer nur die Module aktiv sein, die gerade
ein Objekt transportieren und bei einer beliebigen Ausdehnung des
Systems auch beliebig viele Objekte zeitgleich bewegt werden.
Naja, also werden die wohl übers Wetter reden... oder auch über
Transportobjekte, deren Position, Größe, Geschwindigkeit, etc und Ziel.
Steffen Kleinert schrieb: > @Flo: > An RS232 haben wir auch schon gedacht, wichtig währe dabei aber eine > Realisierung der Schnittstelle mit möglichst wenigen Leitungen. Kann man > uCs auch nur über TxD und RxT verbinden? 3 Leitungen brauchst du mindestens. RxD, TxD und Masse Problem ist eher die Realisierung von 8 UARTS auf einem Modul.
Warum nicht gleich CAN, wie "Schrotty" schon erwähnt hat. Das CAN Modul des Controllers übernimmt dabei automatisch die Dinge, wie Kollisionsauflösung, Filterung, CRC, etc. der "Nachrichten". Kann einem ne Menge Arbeit abnehmen! Keine Adressierung nötig. Nur die "Nachrichten" benötigen eine eindeutige ID. (Sind glaub bis zu 24-Bit - Also viel Spielraum ;-)) Wenn Du AVR's mit CAN nimmst, dann kannst Du mit den MOBs (Message Objects) die Aufgabe recht elegant lösen. Es stehen 15 solche Objekte zur Verfügung. Je nachdem was man benötigt, kann man die beliebig zu RX oder TX Objekten konfigurieren. Allerdings empfehle ich für den Einstieg einen preiswerten CAN-PC-Adapter, damit man das auch Debuggen kann. Ein relativ nettes Teil wäre z.B. von IXXAT der USB-CAN Adapter. Die API für Visual C++ ist auch nicht so schwer, so dass man sich relativ einfach ein Diagnose-Tool schreiben kann. Das mitgelieferte ist zwar in der Lage die Nachrichten anzuzeigen, aber man möchte das ja auch im "Klartext" haben ;-) Randbemerkung: Ich hab hier auch mal ein paar Baugruppen per RS232 bzw. TTL-UART verbinden müssen. Hätten wir das mit CAN gemacht, dann wäre das wesentlich einfacher geworden. Aber die Komplexität hängt von der Anwendung ab!
Kloppt den CAN Muell in die Tonne. Da ist die Messagelaenge auf 6 byte begrenzt. Normales UART ist flexibler.
Ich würde da auch über ein CAN nachdenken, die Vorteile liegen auf der
Hand.
@Matthias
>(Sind glaub bis zu 24-Bit - Also viel Spielraum ;-))
Bei CAN 2.0B sind es sogar 29 Bit.
Genau Zipp, CAN ist definitiv Müll! -- Ironie an -- Darum wird er auch gern in KFZ verwendet und erfreut sich auch in der Automatisierungstechnik einer gewissen Beliebtheit. Schonmal was davon gehört, dass man längere Nachrichten splitten kann? Macht dein Rechner, an dem du gerade sitzt und im Netz surfst, übrigens auch, denn Ethernet ist genau der gleiche Müll, das kann nämlich nur 1500 Byte pro MAC-Frame. Also schlichtweg unmöglich, damit deine Urlaubsbilder zu übertragen. Ich würd da auch auf nen flexiblen UART setzen. -- Ironie aus --
@Zipp
>Da ist die Messagelaenge auf 6 byte begrenzt. Normales UART ist flexibler.
Tut mir leid, aber das ist falsch. Erstens kann ein Frame bis zu 8 Byte
Nutzdaten enthalten, zweitens steht dir noch Platz im Identifier zur
Verfügung.
Der Vergleich mit UART hinkt insofern, dass für jedes Byte der
"Protokoll-Overhead" in Form von Start/Stop-Bit benötigt wird. Analog
dazu kannst du auch bei CAN beliebig viele Frames aneinander reihen.
@Steffen Kleinert >Danke im Voraus für die Hilfe. Ich weiß, das ich ziemlich früh mit >meinen Fragen zu euch komme, aber ich habe etwas Zeitdruck bei dem >Projekt und hätte mich ansonsten auch erstmal 2 weitere Wochen durch >Datenblätter und andere Literatur gewühlt. Wenn in dem Stadium schon Zeitdruck herrscht, ist die Aufgabe vielleicht zu groß für einen Einzelnen. Ich könnte dir evtl. einen Entwickler zur Mitarbeit empfehlen. Interesse?
Du bist noch längst nicht soweit, jetzt schon das Übertragungsmedium festzulegen, das kommt mindestens 10 Projektetappen später. Du mußt erstmal festlegen, wie die Kommunikation organisiert werden soll und ob überhaupt was sinnvolles dabei herauskommt. Und dann mußt Du noch die Datenrate und die Echtzeitanfordungen festlegen. Und irgendwann viel viel später kann man sich dann das passende Übertragungsmedium aussuchen. Stell Dir ein virtuelles Medium vor. Ein Modul stellt eine Anzahl X von Bytes in diese Medium, was soll dann mit diesen Bytes passieren? Ohne Adressierung werden die Bytes dann wohl ewig im Medium umherkreisen. Warscheinlich wirst Du Mann-Jahrhunderte Entwicklungszeit benötigen. Peter
Zum Thema CAN: Ich habe bereits eine sehr umfangreiche Steuerung für ein Vorgängerprojekt mit einem AT90CAN128 realisiert, das auch sehr gut funktioniert hat. Ein Hauptaugenmerk liegt bei dieser Arbeit jedoch bei der Umsetzung eines Kommunikationssystems das ideal ist für das Dezentralisierungskonzept. CAN stellt für die üblichen dezentralisierten Systeme eine sehr gute Basis da, allerdings ermöglicht CAN ebenso wie alle anderen BU-Systeme keine Zeitgleiche Kommunikation mehrerer Teilnehmer untereinander. Ein kleines Beispiel zur Veranschaulichung: Man Stelle sich einen großen Saal voller Menschen vor. Jemand tritt ans Podium und hält eine Rede, angenommen jeder im Saal würde still zuhöhren dann hätten wir ein klassischen Kommunikationssystem, mit einem Master bzw. Sender. Wenn es jetzt zu einer Podiumsdiskussion kommt haben wir den Fall das jeder im Saal sich zu Wort melden kann und ihm alle zuhören. Das währe eine Situtation wie in einem Multimastersystem (bsp. CAN). Realistischer aber ist das sich alle Personen im Saal untereinander mit ihren Nachbarn unterhalten und sich nicht durch die Unterhaltungen der anderen Anwesenden gestört fühlen. Das spiegelt die Art von System wieder die für die Arbeit angestrebt ist. Ich hoffe das macht es etwas verständlicher. Um ein derartiges System zu erzeugen, muss eine "physikalische" Trennung zwischen an der Komunikation beteiligten und passiven/freien Modulen möglch sein, da anderenfalls die Informationen die nur an ein benachbartes Modul gerichtet sind den gesammten Bus blockieren. Ich habe da schon Ideen, die auch noch vorstellen werde, wenn ich sie für ausgereift genug halte. @Loonix Danke für das Angebot, aber das ist für eine Projektarbeit nicht unbedingt zweckmäßig und wenn ich Gas gebe wird das schon was werden.
>Autor: Steffen Kleinert (fenert)
Das klingt nach DSSS
Das heisst, dass du maximal 8 Module im System hast, wovon jedes nur mit seinem unmittelbaren Nachbarn kommuniziert. Sprich: Die Module sind quasi in "Reihe" geschaltet und jedes "sieht" nur seinen Vorgänger und Nachfolger?
Schrotty schrieb: > Das heisst, dass du maximal 8 Module im System hast, wovon jedes nur mit > seinem unmittelbaren Nachbarn kommuniziert. Sprich: Die Module sind > quasi in "Reihe" geschaltet und jedes "sieht" nur seinen Vorgänger und > Nachfolger? Nicht ganz, das System kann prinzipiell aus unbestimmt / unendlich vielen Modulen bestehen. Diese werden schachbrettartig angeordnet, so das jedes Modul 4 (Von-Neumann-Nachbarschaft) oder 8 (Moore-Nachbarschaft) benachbarte Module hat (bzw. auch weniger, wenn Module fehlen).
Steffen Kleinert schrieb: > Nicht ganz, das System kann prinzipiell aus unbestimmt / unendlich > vielen Modulen bestehen. Diese werden schachbrettartig angeordnet, so > das jedes Modul 4 (Von-Neumann-Nachbarschaft) oder 8 > (Moore-Nachbarschaft) benachbarte Module hat (bzw. auch weniger, wenn > Module fehlen). Also im Grunde so, wie das die Transputer vor Jahren gemacht haben. Wenns die noch gibt, wäre das sogar eine Überlegung wert. Die haben die Kommunikationshardware schon eingebaut. Frag mich aber nicht, was sowas heute kostet :-)
Die Frage ist einfach, mit welcher Performance du die Daten übertragen musst. Logisch kannst du natürlich lauter Peer-To-Peer Verbindungen aufbauen, die aber Physikalisch auf einem genmeinsamen Kanal laufen. Um´s mit deinem Raum zu vergleichen: Alle wollen sich unterhalten , aber die Menge der auszutauschenden Informationen ist so gering, dass es ausreichend ist, wenn immer nur einer im Raum redet und die anderen schweigen. Somit hat am Ende des Abends auch jeder alles gesagt, was er loswerden wollte ;-)
@Steffen Kleinert >Danke für das Angebot, aber das ist für eine Projektarbeit nicht >unbedingt zweckmäßig und wenn ich Gas gebe wird das schon was werden. Ok, ich hatte das Projekt als kommerzielles Ansinnen aufgefasst. In dem Fall ist das natürlich nicht zweckmäßig, klar. Viel Erfolg bei diesem interessanten Projekt! (ich freue mich, wenn ich hier dazu was lesen kann)
@Schrotty
>Um´s mit deinem Raum zu vergleichen:
Finde ich gut dargestellt. Es wäre also interessant zu wissen, wie lange
der "Abend" dauert und ob jeder Teilnehmer in dieser Zeit zu Wort kommen
kann.
Wie verbindet man jeden controller mit seinen 8 Nachbarn? Alle auf einen Bus geht ja so nicht, denn dann wuerden sich die Busse teilweise ueberlappen. Es gibt controller, die haben 4 UART, die eher teuren. Aber 8 ?
Software-UART ? Mit niedrigen Baudraten lässt sich das sehr leicht machen. Jeweils ein Port (8 Pins) als Rx festlegen und ein Port als Tx, die lassen sich dann bis auf die verschiedenen Puffer exakt gleich behandeln.
Ich denke daran die Verbindungen mit Tri-state buffern zu blockieren wenn eine Verbindung nicht erlaubt ist. Somit währen die Anschlüsse quasi Sackgassen und nur auf einem Weg ist ein Partner zu erreichen. Diesen Weg bzw. Kommunikationspartner könnte man mit einem "Cabel-Select" auswählen und über die selbe Leitung quasi als "Handshake" eine gleichartige Reaktion beim Empfänger erzwingen. Dadurch währen nur die Module tatsächlich verbunden, welche gerade kommunizieren und alle anderen, auch die unmittelbaren Nachbarn würden nicht beeinflusst. Zum Thema Datenmenge und Datenrate: Das alles ist derzeit recht schwer einzuschätzen, da die endgültige Datenmenge, die zukünftig angestrebt ist nicht nur für mich Neuland ist. Sie sollte aber so gering wie möglich bleiben einige Byte sollten eigentlich reichen. Die Datenrate dagegen wird umso höher sein. Im einfachsten Fall haben wir 2 Nachrichten pro Auftrag / Zyklus. Da die Module sehr klein werden sollen (Kantenlänge <10cm) sind immer mehrere Module aktiv und senden gleichzeitig Nachrichten. Zudem soll die Geschwindigkeit mit der gearbeitet werden soll möglichst groß sein und so komme ich auf etwa 1000 bis 2000 Nachrichten/sec je Objekt auf dem Gesamtsystem wobei das Gesamtsystem im idealfall unbegrenzt ist und schnell mehrere tausend Module haben könnte. Und je größer das Gesamtsystem desto mehr Objekte werden zeitgleich transportiert. Eine Lösung mit mehreren Subnetzen währe sicherlich möglich, aber Ziel der Arbeit ist es auch herauszufinden ob nicht mehr möglich ist. Zudem ist ein System das bidirektionale Kommunikation verwendet genauso zuverlässig mit 10 Modulen und einem Objekt wie mit 1 Million Modulen und 100 Objekten. Oder um es mit meinem Beispiel zu veranschaulichen: Es ist eher ein Singelabend mit Masssenblinddate wo jeder nur kurz Zeit hat sich seinem Gegenüber anzupreisen bevor man schnell zum nächsten Tisch muss (habe keine Erfahrung damit, aber so stelle ich´s mir vor).
Ich würde auf rs232 bei den Standartprotokollen gehen, immer Empfänger optoisoliert. Half Duplex auf zwei Leitungen, Break = Busy und wenn was nicht passt, innerhalbs des Stop-Bits die TX auf high ziehen oder schon vorher, wenn man Rechenzeit braucht und die übertragung wiederholt werden soll. TX-> High= Wait / busy, muss aber gleich oder länger als 10bit sein. TX-> low = warten auf Datenübertragung.
Nach ausgibiger recherche und diversen Überlegungen die Verbindungen mit tristat buffern, Relais u. a. zu sperren habe ich bei meiner Recherche festgestellt, dass es von Atmel eine Controller gibt, der 4 USART-Schnittstellen bereitstellt. Der ATmega2560 scheint daher wie für mich gemacht, alle benachbarten Module können sich ungestört unterhalten es könnten sogar alle Nachbarmodule gleichzeitig mit dem selben Modul "quatschen" oder umgekehrt. 4 eigenständige RS232-SChnittstellen machen es möglich. Der einzige Nachteil ist, dass der 2560 im TQFP-100 Format vorliegt und ich schon einmal einen TQPF-64 mit Hand gelötet habe und nicht erpicht bin das noch zu steigern, zumal ich mehrere Boards löten muss. Aber zum Glück gibt es das hier: http://www.chip45.com/AVR-ATmega-Mikrocontroller-Module/Crumb2560-V1-1-AVR-ATmega2560-USB-RS485-RS232-Modul.html Damit kann ich glaube ich alles machen was ich brauche und habe eigentlich viel zuviel spiel nach oben. aber für eine prototypische Testanlage sollte das akzeptabel sein.
TQFP 100 ist nicht schwierig zu loeten. Niemand loetet da jeden Pin einzeln. Fluxgel drauf, und mit dem zinnbenetzten Kolben drueberziehen. So'n Ding ist in weniger als 1 Minute geloetet.
Hallo, ohne die vielen Anregungen zu unterbrechen, möchte ich einen neuen Ansatz vorstellen : Wenn ich das richtig verstehe, stehen von jedem Modul eine oder mehrere Entscheidungen (von Fahrwegen?) an. Warum versiehst Du Deine Moduel nicht mit einem Transponder mit einer eindeutigen Nummer und liest vor einer Entscheidung den Transponder. Der übergeordnete PC mit Steuerung "endscheidet" wo das Modul hin soll. Die Verwaltung der Modulinhlate ist dann wohl auch einfacher. Datenbanksystem, Aufragsverwaltung, I/O und habe fertig. Gruß Uwe
@Uwe: Das ist genau das was wir nicht wollen. Es soll keine übergeordete Steuerung geben, welche das System kontrolliert. Lediglich eine Datenbank, aus welcher die Informationen über das zu transportierende Objekt beim ersten Kontakt mit dem Modulsystem geladen und dann zusammen mit dem Objekt von Modul zu Modul bewegt werden. Zudem soll das Modul keine eindeutige Bezeichnung haben, damit Module jederzeit gewechselt, entfernt oder hinzugefügt werden können, ohne irgendwelche Einstellungen vornehmen zu müssen.
Module müssen !!! eine eindeutige Bezeichnung haben, schon deshalb, weil z.B ein FW-Upgrade oder ein Defekt vorliegt, und du dann wissen willst, welches Modul das ist, eindeutig. Auch zur Addressierung kann diese eindeutige Nummer gewählt werden, z.B. wenn du einen gemeinsamen Bus zusätzlich hast, z.B. RS232 mit 2400 Baud, um an Module ranzukommen, nenn ihn Servicebus, bzw um unterschiedliche Timeouts bei einem Bussystem zu haben, und so die Systeme zu koordinieren, bzw. automatisch Adressvergabe usw, wo das dann sehr wenig bis nichts mit dem zu tun hat, daß das modul wenn es fehlt problemlos ersetzt werden kann. Z.B. ein Ethernetadapter, wenn er defekt ist, ersett man ihn, der hat auch eine eindeutige Adresse, aber mit DHCP z.B. sowie Routingprotokollen ist der komplett austauschbar. Andererseits, ohne eindeutige Adresse würde dies niemals funktionieren. So ist es vielfach bei uC.
Vielleicht habe ich es etwas falsch ausgedrückt. Natürlich müssen die Module über einen Servicebus bsp. Ethernet ansprechbar sein Dieser Bus darf aber nicht zur Kommunikation der Module untereinander verwendet werden (siehe diverse Beiträge zuvor). Die Bezeichnung der Module währe damit dynamisch und nicht beim Einbau festgelegt, bzw. fest an die Position innerhalb des Gesammtsystems gebunden. Bei "eindeutige Bezeichnung" hatte ich an eine Kennung gedacht, wie ich sie bei einem anderen Projekt verwendet hatte, wobei sich die Kennung auf die Position des Moduls bezogen hatte (in X/Y-Koordinaten) diese Kennung wurde dann auch als Busadresse verwendet.
Schlagt mich, aber ich verstehe die schnelle Ablehnung von Ethernet nicht. Im Prinzip ist das naemlich genau das, was hier die ganze Zeit beschrieben wird. Erstens kann eine Ethernetverbindung auch eine Point-To-Point-Verbindung (also zwische genau 2 Modulen) sein und zweitens laeuft das Ethernet, wie wir es tagtaeglich benutzen, mitnichten ueber einen Bus: Wenn Module A, B, C und D an einem Switch haengen, dann kann A mit B kommunizieren ohne die Unterhaltung von C und D zu stoeren. Eine Adressierung ist nur notwendig, damit der Switch das machen kann, was hier als "Cable Select" beschrieben wird. Aber man kann natuerlich auch das Rad neu erfinden wollen... Volker
Ethernet zieht rabiat Strom, da sollte man schon die Datenrate brauchen.
Verschneiter Tag schrieb:
> Ethernet zieht rabiat Strom, da sollte man schon die Datenrate brauchen.
0.5W waeren fuer mich kein Ausschlusskriterium... und auch nicht rabiat.
Das darf selbst nach neusten Richtlinien ein Geraet schon im Stand-By
verheizen. ;)
Volker
@Volker: Ethernet wäre hier die sprichwörtliche Kanone, mit der man die Spatzen vom Dach schießt. Aber es wäre insofern elegant, dass jedes der Module einen 5-Port-witch dartstellen würde. Ein Port für das Modul an sich mit eigener MAC-Adresse und die anderen vier Ports für die Nachbarmodule. Man könnte sogar von jedem Punkt aus im Netz theoretisch jedes Modul ansprechen, falls es mal notwendig sein sollte.
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.