Hallo, ich hatte hier unlängst mal meine Probleme bei der Auswahl eines Bussystems zur Aprache gebracht, vielen Dank nochmal an alle, die geantwortet hatten. Inzwischen habe ich mich für RS485 als physikalische Schicht entschieden und bin nun dabei, ein für meine Zwecke passendes Protokoll zu definieren. Problem: Ich komme zu keinem Schluß, wie ich der Adressierung realisieren soll. Bei den Geräten handelt es sich um Racks mit je 8 Meßverstärkern. Jedes Rack bekommt eine Controllereinheit, die entweder über Ethernet mit einem PC oder über RS485 mit weiteren Racks verbunden wird. Jener Controller, der am PC hängt, wird dadurch zum Master (Und es hat schon seine Gründe, warum jedes Rack einen vollqualifizierten Controller bekommt, auch wenn das nach OVerkill aussieht...). Die einzelnen Verstärker werden nun in ihren Racks über den Steckplatz adressiert, d.h. die Backplane gibt wor, welche Nummer der Verstärker bekommt. So weit, so gut. Aber jetzt muß ich auch noch den kompletten Racks bzw. ihren Controllern Adressen geben. Da bin ich bisher auf zwei Möglichkeiten gekommen: DIP-Schalter: Vorteil: Es kann bei jedem neuen Versuchsaufbau wieder ein eigener Adressraum definiert werden. Nachteil: Erstens wird garantiert jemand im Falschen Moment unqualifiziert dran herumfummeln und zweitens hat man es mit erheblichem Konfigurationsaufwand zu tun, wenn man Racks, die vorher an verschiedenen Einsatzorten den gleichen Adressraum hatten, in den gleichen Aufbau integrieren möchte. Adresse fest in den Flash des MC (So wie eine MAC-Adresse): Vorteil: Man kann die Adressen fortlaufend für jedes Gerät vergeben, ist Idiotensicher und es kommt nicht zu evtl. Doppelungen. Außerdem entfällt für den User ein großes Stück Konfigurationsaufwand. Nachteil: Man muß die Adressen irgendwie Verwalten, was Aufwand macht und je nachdem, wie lang man die Adressen gemacht hat, ist irgendwann Schluß (Was ein kleineres Problem ist, weil vermutlich mit 16-Bit-Adressen mehr Nummern da sind, wie jemals Racks gebaut werden...). Frage nun: Gibt es da noch andere Lösungen, die vielleicht nicht die genannten Nachteile haben? Wie sieht das bei großen Bussystemen wie z.B. Profibus aus? Wo kommen da die Adressen her? Gruß, Harald
Hm... du könntest das "MaserRack" zu ner art DHCP machen, der jedem angeschlossenem Rack eine Adresse zuordnet :)
Hallo Christoph, >Hm... du könntest das "MaserRack" zu ner art DHCP machen, der jedem >angeschlossenem Rack eine Adresse zuordnet :) das ist ohnehin vorgesehen, löst das Adressierungsproblem aber nicht, da DHCP sich an den MAC-Adressen der einzelnen Rechner orientiert. Um irgendwas in der Art machen zu können, müssen die Busteilnehmer bereits vorher irgenwie unterscheidbar gewesen sein, und da war es wieder, mein Problem ;-). Gruß, Harald
Setze einfach an den Rack-Controller einen Seriennummerchip, dann hat jedes Rack eine weltweit einmalige 48 Bit Seriennummer. Ich nehme dazu den DS18B20 (Maxim), dann hat man nebenbei noch die Rack-Temperatur (nehme ich zur Lüftersteuerung). Peter
@Christoph: DHCP stellt zwar sicher, dass jeder eine eindeutige Adresse hat, aber auch, dass garantiert niemand weiss, welches Gerät wo steckt. Indes dürfte das recht wesentlich zu sein. @Harald: Du hast es schön skizziert. Manuelle Konfiguration signalisiert die Position, ist aber nicht zwingend eindeutig. Automatische Konfiguration ist eindeutig, aber über kurz oder lang weiss niemand mehr welches Teil grad wo steckt und ist somit genauswenig DAU-kompatibel (Variante bei Server-Racks: das entsprechende Excel-Sheet liegt auf dem Server der grad gestorben ist und den man damit sucht). Bliebe nur die automatische geographische Adressierung, aber GPS und Artverwandte kommen wohl nicht in Frage ;-). Unklar ist in deiner Beschreibung freilich das eigentliche Ziel. Muss Mensch in der Lage sein, anhand der Adresse sofort und blind das richtige Rack zu finden?
Hallo Peter, ist eigentlich eine gute Idee, damit wäre die Bürokratie quasi an den Chiphersteller ausgelagert. Ergibt sich folgendes neues Problem: Wenn ich möchte, daß der Master die Adressen der angelschlossenen Racks automatisch erkennt, dann muß ich jetzt 2^48 Adressen zu 48 Bit während des Systemstarts durchhecheln, das dauert bei voraussichtlich 9600 Baud dann 48*2^48 / 9600 [s] = 44627 Jahre bzw. noch länger... Als Alternative müsste ich den Bus multimasterfähig gestalten, was ein bischen viel Aufwand ist, nur um die Adressen zu lesen. Aber mir fällt nicht ein, wie man das anders machen könnte: Schließlich weiß der Master ja vorher nur, daß die Adressen zwischen 0 und 2^48 liegen können...
Hallo, >Unklar ist in deiner Beschreibung freilich das eigentliche Ziel. Muss >Mensch in der Lage sein, anhand der Adresse sofort und blind das >richtige Rack zu finden? ja, denn ich habe ja jeder Adresse eine bestimmte Aufgabe im Prüffeld zugeordnet, z.B. den Druck in einer Brennkammer oder die Temperatur in einer Leitung. Also darf die Information, bei welcher Adresse deiser oder jener Sensor jetzt angeschlossen ist, nicht verlorengehen. Im Gegenteil: Es sollte möglcih sein, das dann am Bildschirm auch noch zu visualisieren. Gruß, Harald
Apropos geographische Adressierung: lässt es sich einrichten, das irgendwas trivial kleines da ist, das sicher nie verschoben wird? Vielleicht im Boden drin, in der Steckdose in der Wand, oder so? Ebendies könnte dann als Basis einer geographische Adressierung dienen. Muss ja nicht mehr tun, als eine Adresse zu liefern. Nicht über den gleichen Bus natürlich, aber da prinzipbedingt kurze Distanz, geht da auch etwas SPI/I2C/1Wire-artiges.
Hallo, >Apropos geographische Adressierung: lässt es sich einrichten, das >irgendwas trivial kleines da ist, das sicher nie verschoben wird? ...wrong way to Hollywood. Die einzelnen Recks werden hier auf dem ganzen Gelände fröhlich auf Wanderschaft gehen. Daher bekommt auch jedes Rack eine Controllereinheit mit der Möglichkeit, direkt ans Ethernet zu gehen (Die also entweder Master oder Slave sein kann) und nicht nur eins. Damit hab ich dann nämlich immer vollqualifizierte Blöcke zu je acht Messkanälen, die ich mit mir ´rumtragen kann, ohne an noch was denken zu müssen. Gruß, Harald
du könntest ja deinen master und die slaves wie folgt konfigurieren. master senden request: bitte adressen bekannt geben! slaves wollen alle antworten und erkennen durch die verschiedenen adressen eien überbelegung -> alle gehen zurück auf anfang. nach einer zufälligen zeit x fangt dann der slave A an zu senden. somit bekommen alle andern slaves mit das der bus belegt ist. der master bekomme die adresse von A und bestätigt das er sie jetzt kennt. slave A ist für die adressenabfrage nun für eine bestimmt zeit deaktiviert. master sendet dann wieder request. wieder kollision am bus -> ein master sendet dann nach erkennung seine adresse und wird wieder bestätigt und für eine zeit gesperrt, .... bis alle slave bekannt sind - bekommt der master nach eine gewissen zeit (time out) mit wenn halt kein slave mehr antwortet. somit hast du dann eine tabelle aller slave im master controller. jetzt musst du dann "nur" mehr jeder 48bittigen adresse eine eindeutige geonummer zuweisen. das wars. zugegeben softwaremäßig und protokollmäßig ein aufwand
Nicht im Rack selbst... Im Boden oder neben der Ethernet-Steckdose in der Wand. Wenn auch das nicht geht, bleibt wohl wirklich nur GPS ;-).
Hallo,
>Nicht im Rack selbst...
war schon klar. Aber das Rack kann an den verschiedensten Orten zum
Einsatz kommen; ich müsste also gut 10 Hektar Betriebsgelände mit
solchen Positionsbaken pflastern...
...oder ich hab da was nicht verstanden.
Gruß,
Harald
Hallo Chriss,
>[Chris:Vorschlag für Arbitrierungsverfahren]
habe ich auch schon überlegt, muß aber erst mal schauen, ob
RS485-Treiber überhaupt Arbitrierungsmechanismen vorsehen. (Vielleicht
weiß das ja auch hier jemand...) Schließlich muß ich ja die Kollision
irgendwie auf der PHY-Layer erkennen können, bevor ich mit Software
anfange... ...oder?
Gruß,
Harald
Ja, so war's gemeint. Ist nicht wirklich sehr aufwendig. Peter hat schon auf die dafür geeigneten Dallas 1-Wires hingewiesen. Kostet pro Bake 1x DS18x20 plus Telefondose in der Wand. Abwägung ist nun deine Sache - soll es sicher sein, oder darf auch manuelle Verwaltung von Adressen sein. Letztere hast Du selber ausgeschlossen.
ALso ich würde Chris Idee zustimmen, der Master sollte ne Art Ping senden, dann antwortet der Slave mit seiner Adresse (man könnte es ja sogar so machen, das der Slave sobald er Angeschlossen wird einen Ping an den Master sendet, ihm seine Adresse und aufgabe mitteilt, z.b. Adresse AA81C3CF, Code 130 (Temperaturstewurungsmodul) oder sowas in der Art) Dasw hätte den Vorteil: * Der Master muss nicht nach Slaves "scannen" diese melden sich * Der Master hat ne Tabelle aller Adressen + Funktion * DAU freundlich ;) Wenn nen Rack abgesteckt wird kann es ja nen Loggof senden, oder der master prüft alle angeshclossenen geräte alle 500ms einmal und kickt nicht antwortende aus seiner Liste) * Du kannst den AdressierungsChip benutzen ;)
um zu verhindern das sich alle gleichzeitig melden kann man ja die Verzöggerung der einzelnen Teile aus der 48bit Adresse bestimmen also mittels Multiplikator o. Divisor eine Verzögerung berechnen.
Hallo Thomas, die idee hatte ich auch schon. Geht aber nicht, weil diese Zeit bei 48 bit Adressraum irgendwann zu groß wird. beispiel: Wenn ich einfach Adresse * 1us nehme, dann errechnet sich die längste Zeit zu tmax = 8,926 Jahre. Und ich denke, als kleinstes Zeitintervall wird nichts wesenlich kürzeres als 1us in Frage kommen. (Selbst für nur 1 ns wäre noch immer tmax = 3,26 Tage... ...d.h. der Verstärker mit der Adresse 0xFFFFFFFFFFFF würde erst nach 3,26 Tagen antworten...)
@Harald "Wenn ich einfach Adresse * 1us nehme, dann errechnet sich die längste Zeit zu tmax = 8,926 Jahre." Nicht so kompliziert denken. Nimm die ersten 4 Bits fürs Delay und wenns kollidiert, die nächten 4 Bit usw. bis einer gewinnt. Oder noch einfacher, vergiß RS485, nimm einfach CAN 2.0B und Du kannst bis zu 29 Bit in den Identifier packen, die dann kollisionsfrei aufgelöst werden. Und für den Fall, diese 29 Bit sind gleich, muß eben noch ein 2. Erkennungslauf mit den nächsten 19 Bits folgen (bzw. 2 Durchläufe mit je 24 Bits). CAN ist eh softwaremäßig viel viel einfacher, da die Hardware den Großteil Protokollkrams schon selber macht. Peter
Hallo Peter,
>[CAN-Bus...]
ursprünglich hatte ich den CAN-Bus eigentlich auch vorgesehen,
allerdings erschien er mir für diese vordergründig simple Anwendung
dann doch etwas schwergewichtig. Aber wenn bei all den Detailproblemen
kommt der dann doch wieder ins Spiel...
Vor allem habe ich bei kann keine ungeklärten Arbitrierungsfragen.
(Bietet RS485 überhaupt eine Kollisionsdetektion?).
Schau´ mer mal... ...aber es lochnt sich doch mal wieder, theoretisch
tiefer ins Detail zu gehen, bevor man in medias res geht.
Gruß,
Harald
Ich weiss nicht ob es dir was hilft: Wenn du eine schnelle Möglichkeit zur Adressneuprogrammierung suchst, wir machen das über einen Taster, die Platine geht in den Programmiermodus und der Mann an der Software sagt dann "Adresse 27". Da nur das eine Modul auf den Adressbefehl hört (wegen der gedrückten Taste), kannst du das Adressierungskommando auf den ganzen Bus rausschrein. Die Platine bestätigt die neue Adresse durch blinken und geht aus dem Adressprogrammiermodus raus (nach dem Speichern der Adresse im EEPROM).
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.