Ich suche eine Möglichkeit, eine unbekannte Anzahl von Teilnehmern (alle gleich aufgebaut) auf einer RS-485 Topologie (2-Draht, 1 Master und n Slaves) zu adressieren. Hard- und Softwaremäßig ist alles klar, solange jeder Teilnehmer eine bekannte Adresse im System hat. Nun will ich zusätzliche Adressleitungen oder fest eingestellte IDs der einzelnen Teilnehmer abschaffen und eine ID jedem Teilnehmer am Anfang automatisch vergeben. Ich habe hier schon 2 Beiträge dazu gefunden, die aber keine richtige Lösung brachten. Wie könnte sowas gehen?
Matthias K. schrieb: > Nun will ich zusätzliche Adressleitungen oder fest eingestellte IDs der > einzelnen Teilnehmer abschaffen und eine ID jedem Teilnehmer am Anfang > automatisch vergeben. Hallo, wie soll das System dann wissen, welcher Slave z.B. die X-Achse und welcher die Y-Achse ist? Oder wer das Voltmeter und wer der Funktionsgenerator? Gruss Reinhard
wenn zu Beginn alle Teilnehmer gleichzeitig Fritz heißen wirds da schon eng. Wird bei der Installation von jedem einzelnen Hugo der Bus vom Master gescannt geht das schon einfacher.
Hallo Matthias Gemacht habe Ich das so noch nicht, vorgehen würde Ich aber so: Eine Nachricht wird definiert, mit der ein Master nach Clients suchen kann die noch keine ID bekommen haben. Diese wird dann durch den Master in der Startup-Phase mehrfach gesendet. Alle Clients die noch keine ID haben können auf diese Nachricht antworten. Alle anderen Nachrichten müssen diese nicht konfigurierten Clients in diesem Zustand ignorieren. Vor der Antwort legt der Client eine zufällige Wartezeit ein, in der auf dem Bus nur gelauscht wird. Geantwortet wird nur, wenn in dieser Wartezeit nichts auf dem Bus gesendet wurde. Der Server kann dann dem Client wieder eine Antwort schicken, mit dem dieser dann eine Adresse zugewiesen bekommt. Die Größe der zufälligen Zahl die die Wartezeit bestimmt ist dann verantwortlich für die Wahrscheinlichkeit, das zwei Clients die gleiche Adresse bekommen. Je nachdem wieviele Clients und wie groß der Schaden bei doppelt vorhandenen IDs sollte das dann angepasst werden. Eine große Wartezeit macht das Startup aber auch sehr langsam. Ein anderer Weg wäre es die 'Multimaster-Fähigkeit' des 485 auszunutzen. Basis wäre dies hier Beitrag "RS485 Funktionen", Thema Arbitrierung. Die Slaves brauchen dann nicht zufällig zu warten sondern legen (alle gleichzeitig) eine zufällige Adresse auf den Bus. Wie bei I2C oder CAN könnte dann ein Slave gefunden werden, der dann mit einer Busadresse versorgt wird. Gruß Klaus
klkl schrieb: > Eine Nachricht wird definiert, mit der ein Master nach Clients suchen > kann die noch keine ID bekommen haben. .. Soweit so schön, aber woher weiss jetzt der Master, welcher Client welche Funktion ausübt? Aus der ID geht das nicht hervor, die hat er ja selbst vergeben. Und wenn man dafür eine Kennzeichnung vorsieht, hat man sich nur einmal im Kreis gedreht und ist wieder am Ausgangspunkt gelandet - der Fragesteller wollte eben NICHTS fest vergeben. Gruss Reinhard
Wenn sich die Slaves durch eine Seriennummer unterscheiden kann man damit arbeiten.
Reinhard Kern schrieb: > wie soll das System dann wissen, welcher Slave z.B. die X-Achse und > welcher die Y-Achse ist? Das muss irgendwie eingestellt werden, richtig. Trotzdem macht das eine automatische Adressvergabe nicht nutzlos, z.B. weil man damit am Slave selbst keine Einstellmöglichkeit vorsehen muss, sondern das bequem an einer zentralen Stelle mit ordentlichem Benutzerinterface machen kann. > Oder wer das Voltmeter und wer der > Funktionsgenerator? Naja, es sollte wohl trivial sein, dass der Slave dem Master mitteilt, was für ein Gerätetyp er ist. Zur Adressvergabe noch eine Idee, die allerdings ein bisschen Hardwareaufwand mitbringt: der Slave ist so aufgebaut, dass er im unkonfigurierten Zustand den RS485-Bus auftrennt. So kann der Master immer nur den Bus bis zum ersten Slave ohne Adresse "sehen", und damit kann es am aktiven Bus immer nur maximal einen unkonfigurierten Slave geben. Sobald der Slave konfiguriert wurde, wird der Bus durchverbunden, und der Master kann sich dem nächsten Slave widmen. Andreas
FireWire hat ein eigenes Verfahren, um bei Veränderungen der Busteilnehmer jedem eine eindeutige ID zuzuweisen. In wieweit das wegen der Punkt-zu-Punkt-Verbindungen von FireWire auf einen RS485 Bus übertragbar ist, weiß ich nicht. In der Wikipedia habe ich auch leider keine Infos darüber gefunden, und die Vorlesungsunterlagen zu dem Thema habe ich leider gerade nicht zu Hand. Aber irgendwo im Internet wird sich's finden.
Andreas Ferber schrieb: > Naja, es sollte wohl trivial sein, dass der Slave dem Master mitteilt, > was für ein Gerätetyp er ist. Wenn mehrere gleiche Gerätetypen vorkommen, geht das vermutlich nicht. Wer ist dann Voltmeter 1, 2 und 3, um bei dem Bsp. zu bleiben? > Zur Adressvergabe noch eine Idee, die allerdings ein bisschen > Hardwareaufwand mitbringt: der Slave ist so aufgebaut, dass er im > unkonfigurierten Zustand den RS485-Bus auftrennt. So kann der Master > immer nur den Bus bis zum ersten Slave ohne Adresse "sehen", und damit > kann es am aktiven Bus immer nur maximal einen unkonfigurierten Slave > geben. Sobald der Slave konfiguriert wurde, wird der Bus durchverbunden, > und der Master kann sich dem nächsten Slave widmen. Wie soll der Master den Slave dann das erste mal erreichen, um ihn zu konfigurieren?
Matthias K. schrieb: > Wie soll der Master den Slave dann das erste mal erreichen, um ihn zu > konfigurieren? Standardadresse. Andreas
Ich hätte da eine Idee: Jeder Slave hat zwei Ports: IN zum Master oder vorherigem Slave und THRU zum nachfolgenden Slave. Im Anfangszustand ist der Bus zwischen IN und THRU unterbrochen und auf Terminierung geschaltet. Der Master schickt sein Konfigurationskommando auf die Standardadresse. Weil der Bus ja nur bis zum ersten Gerät reicht, kann auch nur dieses hören und antworten. Ist das erste Gerät konfiguriert, bestätigt es dies und schaltet den Bus zur THRU-Buchse durch, so dass jetzt auch das nachfolgende Gerät angeklemmt ist. Nächster Durchlauf: Gerät 1 hat jetzt seine Adresse und ignoriert die Konfigurationsnachricht, nur Gerät 2 bearbeitet sie jetzt. usw usw. Wenn Du eine Erkennung einbauen kannst, ob am THRU-Port überhaupt ein Gerät angeschlossen ist (Brücke im Stecker oder Durchmessen der Leitung auf die Terminierung des nächsten Gerätes), dann kann das letzte Gerät sagen "Konfiguriert, und ich bin das letzte Gerät". Damit vermeidest Du, dass das letzte Gerät den Bus auf einen leeren THRU durchschaltet und der Bus damit unterminiert ist. Diese Einrichtung wäre auch beim Master sinnvoll. Die Busterminierung macht in dieser Architektur immer der Master und das letzte Gerät. Was jetzt noch fehlt, ist eine Strategie für Kabelunterbrechungen. fchk
Ich denke es wird zu aufwändig. Wahrscheinlich bleibe ich bei einer festen Kennung für jeden Teilnehmer. Dann ist die Hardware noch am einfachsten.
Frank K. schrieb: > Jeder Slave hat zwei Ports: IN zum Master oder vorherigem Slave und THRU > zum nachfolgenden Slave. Im Anfangszustand ist der Bus zwischen IN und > THRU unterbrochen und auf Terminierung geschaltet. Schön dass du meinen Vorschlag von oben nochmal wiederholst. > Wenn Du eine Erkennung einbauen kannst, ob am THRU-Port überhaupt ein > Gerät angeschlossen ist (Brücke im Stecker oder Durchmessen der Leitung > auf die Terminierung des nächsten Gerätes), dann kann das letzte Gerät > sagen "Konfiguriert, und ich bin das letzte Gerät". Kann man machen, aber nicht nötig (und nochmal Zusatzaufwand). Wenn alle Slaves konfiguriert sind, reagiert nichts mehr auf die Standardadresse, kurzer Timeout, fertig. > Damit vermeidest Du, > dass das letzte Gerät den Bus auf einen leeren THRU durchschaltet und > der Bus damit unterminiert ist. Terminierungsstecker am Ende. Andreas
Matthias K. schrieb: > Nun will ich zusätzliche Adressleitungen oder fest eingestellte IDs der > einzelnen Teilnehmer abschaffen und eine ID jedem Teilnehmer am Anfang > automatisch vergeben. RFC 2131 Das ist zwar eigentlich für IP Adressen gedacht, lässt sich aber 1:1 auch für RS485 Adressen verwenden.
Thomas S. schrieb: > RFC 2131 > > Das ist zwar eigentlich für IP Adressen gedacht, lässt sich aber 1:1 > auch für RS485 Adressen verwenden. Ähm, nein. DHCP wird erstens vom Client initiiert, und zweitens löst es nicht das Problem mit möglichen Buskollisionen, die bei RS485 eben nicht auftreten dürfen. Andreas
@Andreas Ferber: ups, den Absatz hatte ich wohl überlesen. Die Terminierung würde ich trotzdem nicht mit einem Endstecker machen wollen wegen User-too-doof-Error. Außerdem kann man dann solche Sachen wie Kabelbruch mittendrin wenigstens teilweise abfangen, ohne daß gleich der ganze Bus tot ist. @Thomas S.: Das geht nur deswegen, weil jedes Ethernet-Gerät eine eindeutige MAC-Adresse hat. Die gibts hier nicht. fchk
>wegen User-too-doof-Error Bei Profibus hat jeder Elektriker auch immer das Problem. Dafür gibt es spezielle SUB-D Stecker mit Platine drin. Auf der Platine ist ein Widerstand und ein Schalter. In der Doku steht dann: Am Anfang und Ende muss der Schalter "ON" sein, bei allen Stationen dazwischen "OFF". Die Idee mit den Endsteckern ist schon sicher 20 Jahre alt und es gibt diese sogar richtig zu kaufen. Schon sehr lange. Beispiel: http://www.reichelt.de/?ACTION=3;GROUP=C1217;GROUPID=3208;ARTICLE=41082;SID=324NC6aqwQASAAACHraoQ02a3cc33a0a590023a5731e9a0b35b3e
hmmm ... den slaves nen DS1820 verpassen, die haben ne Adresse vorgefertigt mit drauf, somit hat jeder Slave ne "mac-Adresse" und man kann die Temperatur der Schaltung abfragen.
Frank K. schrieb: > @Thomas S.: Das geht nur deswegen, weil jedes Ethernet-Gerät eine > eindeutige MAC-Adresse hat. Die gibts hier nicht. Wie kommst Du darauf? DHCP braucht die MAC-Adresse an keiner Stelle.
Thomas S. schrieb: > DHCP braucht die MAC-Adresse an keiner Stelle. DHCP benötigt eine im Netz eindeutige Identifikation des Clients und dazu wird, weil sowieso vorhanden, die MAC-Adresse verwendet. Wenn man per DHCP feste Adressen vergibt, dann konfiguriert man die ausserdem auf die MAC-Adresse des Clients.
Der DS1820: "DS1820 No Longer Available: Use Recommended Replacements" Wie heißt der Ersatz? Ich meine einen mit Seriennummer.
DS18S20 = DS1820, der DS18B20 ist ähnlich. Es gibt solche 1-Wire Dinger aber auch ohne Temperatur allein für Seriennummern: DS2401.
Ja, stimmt. Gibts ja auch bei Farnell. Ich sehe gerade, die kosten ja ein Vermögen. Kennst Du einen Typ mit Seriennummer, der günstig ist (Auch ohne Temp.Mess)?
Bei TME ist er billiger. Ein Cent-Artikel ist es trotzdem nicht. Im Prinzip tut es jedes 1-Wire Teil.
Bei noch überschauberem Netz kann man das Problem der ID-Vergabe auch pinsparend mit einem ADC-Eingang und zwei Widerständen lösen. Dieser Pin kann gleichzeitig auch als Ausgang für eine pullupfreie CMOS-Last verwendet werden.
Thomas S. schrieb: > DHCP braucht die MAC-Adresse an keiner Stelle. Aber sicher doch. Im RFC wirst du aber durchgängig nur "hardware address" als Begriff finden, da es DHCP nicht nur auf Ethernet gibt. Mal abgesehen davon, dass viele DHCP-Server die Hardware-Adresse benutzen, um einzelnen Clients feste IP-Adressen zuzuweisen, wird sie vor allem auch logischerweise gebraucht, um die Antworten dem Client definiert zustellen zu können. IP hat er ja eben gerade noch keine. Überleg mal, was sonst passieren würde, wenn mehrere Clients gleichzeitig einen DHCP-Bootstrap versuchen. Andreas
Andreas Ferber schrieb: > wird sie > vor allem auch logischerweise gebraucht, um die Antworten dem Client > definiert zustellen zu können. IP hat er ja eben gerade noch keine. > Überleg mal, was sonst passieren würde, wenn mehrere Clients > gleichzeitig einen DHCP-Bootstrap versuchen. Vermutest Du das, oder hast Du den RFC gelesen? In DHCP werden alle Pakete als Broadcast geschickt, Die Mac Adresse wird nicht genutzt! Deshalb braucht es, logischerweise, einen anderen Mechanismus, wenn mehrere Clients gleichzeitig einen DHCP-Bootstrap versuchen. DHCP verwendet dazu die "Transaction-ID" eine 4-Byte Zufallszahl. Richtig ist, dass manche DHCP Server die Mac Adresse benutzen, um feste IP Adressen zu vergeben. Dies muss man aber nicht so machen. Viel Sinnvoller ist es, dazu den "Host Name" zu verwenden. Dies ist ein String, der dazu gedacht ist, den Teilnehmer zu identifizieren, könnte also in diesem Beispiel z.B. "Termperatursensor" heißen.
Wenn im Netzwerk Speicher vorhanden ist, dann ist die augenscheinlichste Möglichkeit, sich neu anmeldende Geräte als Sortierungskriterium zu nehmen. Es handelt sich also um eine zeitlich organisierte Arbeitsweise. Also du steckst irgendwo im laufenden Netz ein Gerät an den Bus und dieses meldet sich beim Master auf einer 'Broadcast'-'Anmelde'adresse. Der Master gibt ihm daraufhin z.B. die Indexadresse, auf der der neue Teilnehmer nun in der Liste im Master verwaltet wird. Der Teilnehmer hat nur eine EINDEUTIGE Adresse. Solange man nur als Einziger am Netz bastelt, wird es nie zwei gleichzeitige Versuche geben, eine eigene Adresse zu beziehen. Klar muß man da noch einige Feinheiten beachten. Würde jetzt zu lange dauern, das alles hier darzustellen. Das wäre die eine Möglichkeit. Die andere wäre über eine Zufallszahl (womit der DS2401 eingeschlossen ist). Mit der Zufallszahl wird eine Priorisierung durchgeführt. Die kann z.B. bei RS485 auch in Hardware auf Bitebene passieren, z.B. wenn ein Zustand auf dem Bus dominierend ist. Eigentlich alles alter Tobak. Ich habe nur gerade keine Referenz zur Hand.
Thomas S. schrieb: > In DHCP werden alle Pakete als Broadcast geschickt, Die Mac Adresse wird > nicht genutzt! Dann muss ich wohl ein anderes DHCP haben: 18:57:54.896492 00:16:41:72:77:f1 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 1400: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:16:41:72:77:f1, length 1358 18:57:54.899093 00:25:86:e4:d1:39 > 00:16:41:72:77:f1, ethertype IPv4 (0x0800), length 342: 192.168.42.1.67 > 192.168.42.90.68: BOOTP/DHCP, Reply, length 300 > Deshalb braucht es, logischerweise, einen anderen Mechanismus, wenn > mehrere Clients gleichzeitig einen DHCP-Bootstrap versuchen. > DHCP verwendet dazu die "Transaction-ID" eine 4-Byte Zufallszahl. OK, stimmt. Trotzdem wird üblicherweise die Serverantwort via Unicast ausgeliefert. Clause 4.1, drittletzter Absatz. Das ändert aber nichts daran, dass es für RS485 nicht taugt, da es eben keine Kollisionen verhindert. Andreas
Thomas S. schrieb: > Vermutest Du das, oder hast Du den RFC gelesen? > > In DHCP werden alle Pakete als Broadcast geschickt, Die Mac Adresse wird > nicht genutzt! Ich lese das etwas anders. Es ist im RFC zwar nicht festgelegt, welche eindeutige Identifikation als Basis verwendet wird, eine irgendwie geartete im Netz eindeutige Identifikation muss aber bereits vorhanden sein. Das kann eine MAC-Adresse sein, eine Telefonnummer oder was auch immer. DHCP kann diese eindeutige ID in eine andere eindeutige ID (die IP-Adresse) umwandeln. Aber keine eindeutige ID frei erfinden wenn nicht schon vorher eine existierte. Insofern ist damit für das hiesige Problem nichts gewonnen. Siehe "chaddr" Feld im DHCP.
> Und wenn man dafür eine Kennzeichnung vorsieht, hat man sich nur einmal > im Kreis gedreht und ist wieder am Ausgangspunkt gelandet - der > Fragesteller wollte eben NICHTS fest vergeben. Es ging bisher nur um die Anmeldung auf dem Bus. Die Funktionalität der einzelnen Geräte festzulegen ist ein anderes Problem, das in manchen (sehr seltenen) Fällen auch nicht notwendig ist. Beispiel wäre eine Alarmierung ohne den Ort des aufgetretenen Alarmes über den Bus kommunizieren zu müssen. Evtl. kann man den Geräten Ihr Funktion über die Verkabelung definieren...? Gruß Klaus
>Evtl. kann man den Geräten Ihr Funktion über die Verkabelung >definieren...? Evtl. kann man das einmal Adressierte Gerät auch fragen was es denn tut... Wie automatisch und wie oft soll deine Initialisierung denn ablaufen? Eine möglichkeit wäre die Adressen dynamisch von Hand zu vergeben. Wenn du ihrgend eine Möglichkeit hast deinem Slave zu sagen, dass du etwas von ihm Willst (Taster oder sonst was) kannst du den Master in einen Modus versetzten, in dem er auf den Bus standart anfragen pollt. Wird jetzt der Taster o.ä. an einem Slave gedrückt, Antwortet dieser und bekommt eine Adresse. Dadurch kann der Nutzer auch die Reihenfolge und somit die Position festlegen, was ja bei einer Alarmanlage nicht ganz Blöd sein könnte. Das ist jedoch nur eine Variante, wenn du sehr selten neu adressieren musst. um es 4mal am Tag zu machen ist dies deutlcih zu aufwendig. Gruß Daniel
Man sollte immer mit einem Stromausfall rechnen. Danach sollte ein System wieder von selbst anfahren koennen. Auch wenn es noch eine manuelle Quittierung benoetigt.
Nabend, ich befasse mich momentan auch mit diesem Thema. Ich bin dabei einen Bus zu entwerfen. Dabei hab ich am Anfang einen Buskoppler und nacheinander, über einen Rückwandbus versorgt, die IOs. Für den Rückwandbus würde ich nun auch gerne RS485 nehmen. Wegen der Geschwindigkeit würde ich SPI nehmen und dann mit einem MAX3140 auf den Bus gehen. Nun soll bei Spannungszufuhr, wenn die IOs noch keine Adresse haben, der Bus adressiert werden. Und wenn man während des Betriebs einen ausrauscht, soll der Bus ganz normal weiterlaufen, deswegen hab ich auch den Rückwandbus. Wenn man dann eine Gerät wieder einfügt, soll es automatisch seine Adresse bekommen vom Master. Und nun bin ich am überlegen, wie ich die Adressvergabe realisiere.
Wenn man eine Backplane hat kommt es moeglicherweise auf die Reihenfolge an. Dann sollte man die Backplane mit einem pin je daran beteiligen. Autoadressierung macht nur Sinn, wenn alle Devices mehr oder weniger Identisch und Standalone sind, mit einer Funktionalitaet nur fuer sich. Und auch dort muss man die Positionsverkerkung irgendwie gelost haben, zB fuer einen Fehlerfall. zB bei Kuehlcontainern auf einem Schiff oder im Hafen. Dort interessiert die Position (fuer das Ueberwachungssystem) erst im Fehlerfall. Die Beladung ist davon unabhaengig.
Ich nutze dieses System https://www.phoenixcontact.com/assets/images_ed/global/web_content/pic_con_a_0042773_int.jpg Und da hab ich nur 16 Kontakte zur Verfügung. Zwei davon sind offen, falls man was durchschleifen will. Quasi daisy-chain. Also die Slaves sind alle identisch, haben sogar alle dieselbe Firmware drauf. Per Kodierung wird denen nur gesagt ob sie jetzt 8 Eingänge sind oder 8 Ausgänge oder 4 Ein-/4 Ausgänge sind. Und ich will halt das versuchen, was bei Siemens, Wago, Beckhoff, Phoenix nicht geht. Sozusagen ein Plug-And-Play Bus. Der Master soll dann nacheinander selber die Slaves den Modbus-Registern zuordnen.
Wenn's denn sein muss .... Jedes Device enthaelt eine eindeutige ID, zB die Seriennummer. Der Busmaster gibt den Befehl : Ein Device, das noch nicht angemeldet ist soll sich melden, falls eine im Device errechnete Zufallszahl XOR die ID, AND eine mitgegebene Wahrscheinlichkeit ungleich Null ist. Wenn die Wahrscheinlichkeit zu tief ist, meldet sich lange nichts. Falls die Wahrscheinlichkeit zu hoch ist gibt es Kollisionen, und der Master sieht auch nichts. Also meldet sich irgendwann etwas, dem wird dann die feste ID zugewiesen, und von dem bestaetigt.
:
Bearbeitet durch User
Wenn man RS-485 am Master mit drei Widerständen terminiert (failsafe terminator) hat man einen definierten Ruhe-Pegel. Damit kann man die ID-Suche/Vergabe wie beim 1-wire-Bus mit der Seriennr. machen. Die Slaves senden dabei immer nur ein BREAK für ein einzelnes Bit. Im Idealfall benutzt man dabei den DE des 485-Treibers während der DI dauernd aktiv bleibt. Dadurch gibt es keine harten Kollisionen (die logischen Kollisionen gehören ja zum Protokoll).
Und wie soll ich erkennen an welche Stelle sie am Bus sind?
Markus M. schrieb: > Ich sehe gerade, die kosten ja ein Vermögen. 50ct für eine gute Seriennummer ist doch zu verschmerzen. Dafür kannst du nicht soviel Alternativkasperei veranstalten. Oder hast du einen Exklusivvertrag mit Farnell? Früher (TM) konnte man auch "A"s einzeln kaufen ;-) ebay 151424575620
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.