mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RS-485 Teilnehmer-Adressvergabe automatisch


Autor: Matthias K. (matthiask)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: weinbauer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: klkl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn sich die Slaves durch eine Seriennummer unterscheiden kann man 
damit arbeiten.

Autor: Matthias K. (matthiask)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vermutlich geht es ohne Serien-Nr. nicht.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Maik Fox (sabuty) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias K. (matthiask)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias K. schrieb:
> Wie soll der Master den Slave dann das erste mal erreichen, um ihn zu
> konfigurieren?

Standardadresse.

Andreas

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias K. (matthiask)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas S. (klegom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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;GROUP...

Autor: Weingut Pfalz (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas S. (klegom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der DS1820:
"DS1820 No Longer Available: Use Recommended Replacements"

Wie heißt der Ersatz?
Ich meine einen mit Seriennummer.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DS18S20 = DS1820, der DS18B20 ist ähnlich. Es gibt solche 1-Wire Dinger 
aber auch ohne Temperatur allein für Seriennummern: DS2401.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei TME ist er billiger. Ein Cent-Artikel ist es trotzdem nicht. Im 
Prinzip tut es jedes 1-Wire Teil.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es nur um die Seriennummer geht, dann ist der DS2401 günstiger.

Autor: Thomas S. (klegom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Kloos (klkl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Daniel G. (daniel83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man sollte immer mit einem Stromausfall rechnen. Danach sollte ein 
System wieder von selbst anfahren koennen. Auch wenn es noch eine 
manuelle Quittierung benoetigt.

Autor: Mathias O. (m-obi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sapperlot W. (jetztnicht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mathias O. (m-obi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nutze dieses System
https://www.phoenixcontact.com/assets/images_ed/gl...
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.

Autor: Sapperlot W. (jetztnicht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: eagle user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Mathias O. (m-obi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wie soll ich erkennen an welche Stelle sie am Bus sind?

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mathias O. (m-obi)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Naja wer weiß wie es vor 5 Jahren war.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.