mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik plug & play Fähigkeit auf RS-485 Bus


Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ist es irgendwie möglich einen RS-485-Bus "plug&play"-fähig zu
bekommen. Ich meine ohne das ich alle Adressen der angeschlossenen
Sensoren und Aktoren vorher im Speicher aufliste.

Ich hatte mir gedacht, daß ich den einzelnen Sensoren und Aktoren
Adressen (Nummern) gebe (EEPROM des Controllers), die dann vom Master
erkannt werden sollen.

Autor: miwitt001 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Ich arbeite zur Zeit auch an so etwas ähnlichem. Ich sehe aber momentan
eher ein Problem darin, dass wenn der Bus "Plug and Play" fähig ist,
er ja in bestimmten Zeitintervallen nach neuen Teilnehmern suchen
müsste. Momentan ist das so gedacht, dass der Master an alle Adressen,
von denen er meint dass dort kein Teilnehmer ist, ein bestimmtes Paket
sendet, und falls zwischenzeitlich dort ein Teilnehmer angeschlossen
wurde, dieser antwortet. Allerdings bremst das meiner Meinung nach den
Bus aus, da in bestimmten Intervallen gesucht werden müsste und
währenddessen kein anderer Teilnehmer senden darf. Außerdem muss man
ein kleines Timeout einbauen, um den Teilnehmern Zeit zum antworten zu
lassen. Um diese unnötige Belastung des Bus zu vermeiden, sucht mein
Master nur nach neuen Teilnehmern, wenn man einen Taster drückt. So
muss ich ihm zwar selber sagen dass er suchen soll, aber ich denke,
dass das besser ist als den Bus unnötig zu belasten.
Mit den Adressen im EEPROM das hab ich mir auch schon überlegt. Ich
werde es wahrscheinlich so machen, dass jeder Teilnehmer zu beginn
seine Adresse aus dem EEPROM liest. Man muss halt dann darauf achten
keine Adresse 2 Mal zu vergeben.
mfg Michael

Autor: leo9 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

warum willst du dieses Scannen weglassen, die Busperformance wird
darunter kaum leiden.
Außerdem brauchst du bei einem 485-Bus ja sowieso einen Master der die
Buszugriffe regelt, oder hast du eine bessere Lösung um Kollisionen zu
vermeiden ?

Ich sehe das Problem eher in der Verkabelung, kommt der neue Teilnehmer
in die Busmitte, wird der Bus beim Einschleifen kurzzeitig in zwei
unabhängige Segmente geteilt (denen dann auch noch jeweils ein
Abschlußwiderstand fehlt). Kommt der neue Teilnehmer ans Ende gibts die
Trennung zwischen Abschluß und Bus.

grüsse leo9

Autor: miwitt001 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Überlegung war folgende: Wenn der Master immer nach einer Sekunde
sucht. und in meinem Bus max 15 Teilnehmer sein können, und er jedem
teilnehmer einen Timeout von 20ms lässt, dann hab ich alle 1 sec eine
Unterbrechung von 0,3 sec, also fast ein viertel der Zeit. Außerdem ist
es in meinem Fall nicht so dass man normalerweise während des Betriebs
Teilnehmer anschließt, sondern das ganze ist eher ein nettes Feature,
man könnte auch das ganze Gerät abschalten und danach wieder an, dann
werden neue Teilnehmer auch erkannt...
mfg Michael

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum muss sich der Master darum kümmern?
Eine Kollisionsprüfung kann man recht einfach dadurch realsieren, dass
man das was man sendet selbst empfängt (Transceiver konstant als
Listener), und dann überprüft.
So kann ein neu hinzugekommener Teilnehmer auch den Bus überwachen und
sich bei nächster Gelegenheit beim Master anmelden, also quasi ein
Temporärer Master.

@Leo:
Warum sollte der Bus bei einem neuen Teilnehmer aufgetrennt werden?
Normalerweise wird der Bus ja nicht durch ein Gerät durchgeschliffen.
Es wäre halt ein Problem der mechanischen Umsetzung.
Die Terminierungswiderstände braucht man eigentlich nur bei sehr hohen
Geschwindigkeiten und langen Kabeln...

Jetzt würde mich noch interessieren, wie häufig es zu einem
Gerätewechsel kommt und wie der Master feststellt, dass ein Gerät
senden will. Wenn man die Slaves sowieso triggern muss, kann man das
auch für alle Geräte der Reihe nach, weil es doch sonst zu endlosen
Kollisionen käme.
Wenn schon dynamisch, dann von Anfang an: Erst nur der Master, der
vergebens auf Antworten wartet. Sobald ein Gerät vorhanden ist, würde
sich dieses ja auch auf die Anfrage mit der entsprechende Adresse
melden.
Eine Art Hardware-Adressierung ist ja sowieso notwendig, damit der
Master die Daten zuordnen kann.

Oder handelt es sich bei den anderen Geräten nur um Anzeigen? Dann
würde sich auch die RS422 eignen. Die hat für jede Richtung ein eigenes
Aderpärchen.

Gruß Rahul

Autor: leo9 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rahul:
"recht einfach dadurch realsieren, dass
man das was man sendet selbst empfängt "
... darin liegt das Problem vieler RS485-Designs, die Bustreiber sind
relativ niederohmig (meist auch kurzschlußfest) und die Pegelerkennung
lautet meist A>B bzw Rx+>Rx-. Wenn nun zwei Treiber gegeneinander
arbeiten reichen bereits die Übergangswiderstände der Stecker damit
jeder Teilnehmer auf seiner Busseite seine gesendeten Daten liest und
von der Kollision nichts mitbekommt.
Wenn man auf R2-485 Ebene ein Multimaster Konzept realisieren will,
kommt man um ein Protokoll mit ACK resp. NACK nicht herum.

Die RS485 ist von den elektrischen Eigenschaften nicht für Kollisionen
bzw. deren Erkennung konzipiert.

grüsse leo9

Autor: miwitt001 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Eine Kollisionsprüfung kann man recht einfach dadurch realsieren, dass
man das was man sendet selbst empfängt (Transceiver konstant als
Listener), und dann überprüft.
So kann ein neu hinzugekommener Teilnehmer auch den Bus überwachen und
sich bei nächster Gelegenheit beim Master anmelden, also quasi ein
Temporärer Master."

@ Rahul: So wie du das beschreibst sehe ich aber noch ein Problem. Mal
angenommen ein Teilnehmer überwacht den Bus und erkennt eine Pause.
Wenn er da sofort etwas sendet um sich beim Master einzubuchen, dann
kann es aber doch sein, dass gleichzeitig ein anderer Teilnehmer zu
senden anfängt und somit wieder nur Datenmüll rauskommt.

Autor: Mario B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
habe da mel eine Frage die da gur hineinpassen würde.

Arbeite gerade an einem dezentralen RS485 Bus. Hat jemand irgendwo ein
ein fertiges Busprotokoll im Netz gefunden (in Basic).

Wie CSMA/CD funktioniert ist mir klar es geht mir mehr um die
Programmierung.


THX
Mario

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

da möchte ich auch gern nochmal eine Frage einwerfen:

Was passiert denn eigentlich, wenn ich keine lange Busleitung nehme,
sondern Sternförmig vom Master weggehe?
Wo ist da dann der elektrische Unterschied?

Wenns denn hier reinpasst, würd ich mich über eine Erklärung freuen...

Dirk

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael,

"Meine Überlegung war folgende: Wenn der Master immer nach einer
Sekunde
sucht. und in meinem Bus max 15 Teilnehmer sein können, und er jedem
teilnehmer einen Timeout von 20ms lässt, dann hab ich alle 1 sec eine
Unterbrechung von 0,3 sec, also fast ein viertel der Zeit."

Warum ?
Zwingt Dich denn jemand, immer alle 15 sofort hintereinander zu suchen
?

Sobalder der Master eine Pause hat, sucht er irgendeinen und in der
nächsten Pause den nächsten usw.


Aber ich weiß schon, warum ich lieber CAN nehme.
Beim Devicenet Protokoll z.B. schreit jeder neue Slave sein
DuplicateMacID raus und fertig.
Und da der CAN ja kollisionsvermeidend ist, gelingt es jedem, der was
senden will, dies auch zu tun.


Peter

Autor: leo9 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:
Der CAN ist nicht kollisionsvermeidend, er ist lediglich im Stande
Kollisionen auf Bit-Ebene zu erkennen und der rezessive Teilnehmer
zieht sich vom Bus zurück.
Das bedeutet eine Kollision kann auftreten, es wird aber das dominante
Datenpaket nicht gestört und es müssen nur die rezessiven Daten
nocheinmal geschickt werden.

grüsse leo9

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CSMA/CA  = Carrier-Sense Multiple Access with Collision Avoidance
                                              ^^^^^^^^^ ^^^^^^^^^
                                              ||||||||| |||||||||


Peter

Autor: leo9 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter: Die Wahrscheinlichkeit dass zwei Teilnehmer zum gleichen
Zeitpunkt auf den Bus wollen ist durch das Zugriffsverfahren zwar
deutlich geringer als in CSMA/CD-Netzen, verhindert werden Kollisionen
dadurch aber nicht.
Der Vorteil von CAN liegt halt einfach darin dass auch bei Auftreten
einer Kollision ein Datenpaket am Bus "überlebt".
Im Gegensatz dazu wird z.B. bei RS-485 die Übertragung unwiderruflich
gestört und beide Stationen müssen nochmals mit der Sendung beginnen.

Einigen wir uns einfach darauf dass eine "nicht destruktive
Kollision" eben "keine echte Kollision" ist, dann stimmt deine
Vermeidung und meine Erkennung.

grüsse leo9

Autor: QuadDash (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist eine Kollision nicht per Definition das Zerstören der vorliegenden
Informationen? Und genau das kann (auch definitionsgemäß) bei CAN nicht
vorkommen.

http://www.lfs-tipps.de/sections.php?op=printpage&... (Abschnitt:
"Was ist eine Kollision?")
beschreibt was eine Kollision auf elektr. Ebene ist. Ich halte das für
aussagekräftig und auf logische Ebene übertragbar.
(Bestätige damit im Prinzip leo9s letzten Absatz).


----, (QuadDash).

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

ich hatte in den letzten Tagen keine Zeit zu antworten.
Danke erstmal für die Antworten.

Ich habe mich entschieden den Bus anders aufzubauen. Ich werde einfach
alle Adressen die ich vergeben habe und vergeben werde im Master
speichern und dann den Bus im Master/Slave Modus arbeiten. Also die
zyklische Abfrage der Slaves. Das ist einfacher.
Die Anzahl der Slaves wird ja bis maximal 30/32 begrenzt sein. Da
reicht eigentlich der EEPROM locker aus.

Nun meine Frage: Gibt es da vielleicht schon "Protokoll-Gerüste"?
Damit ich nicht erst was erfinden muß, was schon da ist. ;-)

Autor: miwitt001 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau mal ob dir das weiterhilft:
http://www.elektronik-projekt.de/include.php?path=...
Dort ist unter anderem ein Protokoll beschrieben. Das funktioniert
allerdings nur, wenn alle Teilnehmer ihr UART auf 9Bit schalten können.
Das geht z.B. mit den AVRs
mfg Michael

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.