Hallo.
In einer Anwendung kommunizieren ein Master und mehrere Slaves über
RS485. Normalerweise wird jedem Slave vom Master mitgeteilt, dass mit
ihm jetzt kommuniziert wird. Dafür gibt es ein "Select" vom Master für
jeden Slave.
Der Master initiiert die Kommunikation.
Leider keine "Request"-Möglichkeit vom Slave zurück zum Master.
Jetzt stehe ich vor dem Problem, dass mehrere Slaves gleichzeitig einen
Job ausführen und sich dann nach dem Job zurückmelden sollen. (nach
300-1200ms)
Leider kann ich nicht genau sagen, wann die Slaves ihre Quittierung
rausschicken (könnten), aber es ist sehr wahrscheinlich nach anhähernd
der gleichen Zeit.
Somit hab ich das Problem, dass mehrere Treiber gleichzeitig auf TX
gehen könnten, was auf die Dauer sicherlich nicht toll ist. Unabhängig
mal, dass man sicherlich nichts vernünftiges mehr Empfangen kann.
Hatte mir schon ein "Polling" vom Master überlegt: Master schaltet die
entsprechenden "Select"-Leitung der Slave, welche quittieren sollen und
der Slave antwortet dann nur in seinem "Zeitfenster", solange das Select
aktiv ist.
Gibt es da noch andere Ansätze? Aber leider ohne die Schaltung zu ändern
;-)
Vielen Dank,
Pepe.
Pepe schrieb:> Gibt es da noch andere Ansätze? Aber leider ohne die Schaltung zu ändern> ;-)
Nur der "Master" darf ungefragt senden. Beim "Slave" kann der Status
abgefragt werden: kurze Frage - kurze Antwort. Wenn er Daten hat, werden
diese bei ihm abgeholt.
Ich hoffe, Du hast keine separate "Select"-Leitung, sondern adressierst
ordentlich?
Nö. Hab separate Select-Leitungen, weil in meiner Anwendung nicht die
Adresse der Slaves, sondern der mechanische Ort benötigt wird.
Adressierung über den Bus bringt mich da nicht wirklich weiter.
Multimaster und RS485 (und das ist es ja, wenn mehr als einer ungefragt
auf dem Bus rumquatschen darf) ist nicht so trivial wie es scheint.
Letzten Endes brauchst du entweder eine Kollisionsvermeidungsstrategie
(wie z.B.CAN) oder zumindest Kollisionserkennung (wie z.B. Ethernet).
Für dein Vorhaben wäre CAN besser geeignet gewesen :-)
Wenn du nun schon mal gebaut hast, bleib beim Singlemaster und denk dir
was aus, wie du ausreichend schnell Senderechte verteilst. Was deine
Select-Leitung soll, weiss ich nicht.
H.Joachim S. schrieb:> Was deine> Select-Leitung soll, weiss ich nicht.
Meine Slaves sind alle gleich. Ich kann jeden dieser Slaves mechanisch
an eine von max. 200 mechanischen Positionen anstecken und muss jetzt
durch das Anstecken die mechanische Position erkennen können. Und dafür
brauch ich ne eindeutige Zuordnung (=Select-Leitung) zum Steckplatz.
Dass sich die dann noch als "TX-Enable Leitung" angeboten hat, war nur
eine Nebensache.
Das ein Slave von sich aus sendet widerspricht dem Master-Slave-Prinzip.
Kollisionen sind dabei vorhersehbar.
Führe doch einen zusätzlichen Befehl ein, der notfalls mit Schweigen
beantwortet werden kann.
Massa weiß ja in welchem Zeitraum eine Antwort kommen sollte.
Oder der eine variable Antwortlänge beinhaltet.
Und das ist dann ein daumendickes Kabel, mit 200 select-Adern und 2
Busleitungen??
Oder 200 4polige, verschaltet als Kampfstern?
edit: Antwort überschnitten.
Pepe schrieb:> Meine Slaves sind alle gleich. Ich kann jeden dieser Slaves mechanisch> an eine von max. 200 mechanischen Positionen anstecken und muss jetzt> durch das Anstecken die mechanische Position erkennen können. Und dafür> brauch ich ne eindeutige Zuordnung (=Select-Leitung) zum Steckplatz.
Was mir da einfällt wäre, an jeder der 200 möglichen Positionen z.B. 8
Widerstände = 8 Bit anzubringen. Jeder Widerstand geht entweder auf Vcc
(=1) oder Gnd (=0). Jetzt hast Du am Slave ne Buchse über die der Slave
die 8 Bits kontaktiert und auslesen kann und dadurch seine Adresse
kennt. Da die Widerstände nur lokal an der Slaveposition sind, sparst Du
Dir die Adern.
Es gibt noch mehr Möglichkeiten für sowas, z.B Spannungsteiler und den
dann mit nem ADC auslesen.
Aber jetzt zu Deinem Multimaster-Problem: wie kritisch ist denn das
Timing? Also muss eine Antwort innerhalb von t Millisekunden beim Master
ankommen oder ist das egal ob die ne Sekunde früher oder später ankommt,
solange sie nicht ganz verloren geht?
Wieviel ist auf dem Bus los? Ist der fast voll ausgelastet oder ist da
noch Luft?
Was Du machen könntest wäre nämlich einfach mit den Kollisionen und
Paketverlusten leben und Deine Strategie daran anpassen. So ähnlich wie
bei TCP. Der Empfänger muss den ordnungsgemäßen Empfang quittieren,
ansonsten versucht es der Absender erneut.
Also du hast statt einer Adressierungsmöglichkeit auf den slaves zu
jedem eine Leitung.
Also machst du folgendes: beim Systemstart werden die Adressen verteilt:
-1.CS auf low, Kommando: hier kommt deine Adresse (1)
Entweder kommt jetzt eine Antwort und der Master weiss jetzt, dass auf
CS1 jemand wohnt und dass der ab jetzt die Adresse 1 hat. Kommt nichts,
ist der Platz leer oder defekt
usw bis du alle durchgeklappert hast. Dann hast du eine Tabelle, welche
Plätze belegt sind und kannst ab da über eine einfache 8bit-Adresse
jeden einzelnen gezielt ansprechen.
Und ab dann pollst du alle vorhandenen:
slave 1, hast du was? (2 Byte)
Antwort nein (1byte) oder den entsprechenden Datensatz
1Mbit geht i.a. problemlos (wie lang ist deine Leitung??), sprich die
Anfrage dauert 20µs pro slave, die (negative) Antwort 10µs. Mit ein
bisschen Latenzzeit bist du bei 50µs pro slave, d.h. in 10ms hast du
alle einmal durch.
@H.Joachim Seifert
So etwa ist das Ganze auch jetzt schon implementiert. Nur hatten wir uns
vor >10 Jahren auf 115Kb eingestellt.
Ich sehe schon, dass ich wohl nicht ums Pollen rum komme. Ehrlich gesagt
hatte ich auch nichts anderes erwartet.
Jetzt was persönliches: Kommst Du aus der SMD Fertigungsecke?
Pepe schrieb:> So etwa ist das Ganze auch jetzt schon implementiert.
Das hattest Du aber nicht geschrieben!
Pepe schrieb:> Adressierung über den Bus bringt mich da nicht wirklich weiter.
... und nichts von bis zu 200 Teilnehmern und 115 kBd.
Wichtig ist es, das Pollen kurz zu halten und nach Prioritäten ablaufen
zu lassen.
Ich hatte mal System gesehen da wurden die Slaves vom Master fortlaufend
durchnummeriert. Auf eine Statusabfrage des Masters hat dann zuerst
Slave1 mit einem Statusbyte geantwortet, dieses hat auch Slave2
empfangen und dann sofort sein Statusbyte gesendet u.s.w. bis alle
Slaves ihren Status gesendet hatten.
Das ganze ging recht flott weil der Master ja nur eine Anfrage an alle
gesendet hat und jeder Slave nur mit einem Byte geantwortet hat.
Im Fehlerfall wenn ein Slave ausgefallen ist mussten die restlichen
natürlich wieder neu durchnummeriert werden.
Über ihre eigentliche Adresse waren die Slaves natürlich auch direkt
erreichbar.
Pepe schrieb:> Und dafür> brauch ich ne eindeutige Zuordnung (=Select-Leitung) zum Steckplatz.
Wieso - die Leitungen sind doch überflüssig. Du kannst jeder Station
durch Jumper oder Verdrahtung am Steckplatz eine positionsabhängige
Nummer geben und der eingesteckte Slave meldet die auf Anfrage, so weiss
der Master, welcher Slave in welchem Steckplatz steckt.
Georg
Georg schrieb:> eine positionsabhängige Nummer geben
Da aber meine Kunden den Slave irgendwo hinstecken wollen, ohne irgend
Jumper zu ändern, geht's wohl trotzdem nur mit einer Steckplatzerkennung
die nichts mit den Slaves zu tun hat. Aber das ist auch gar nicht mein
Thema. Da kann ich eh nichts ändern.
Je nach Häufigkeit, Wahrscheinlichkeit und technischer Möglichkeit
(mehrere CS gleichzietig aktivieren oder Lockerung des bestehenden
Regimes) geht evtl. ein Gruppenbroadcast schneller:
Slaves 1-10 habt Ihr was?
keine Antwort
Slaves 11-20 habt Ihr was?
alle schwatzen los, kein sinnvolles Signal aber Info das was abzuholen
ist hat man ja trotzdem gewonnen.
Slave 11 hast Du?
...
viel Erfolg
hauspapa
Datenblatt Seite 7:
The driver output is protected from shorts between ±60V in both active
and high impedance modes.
Würde ich als "ist einen Versuch Wert" interpretieren
Ausserdem ist CAN Bus Applications Explizit aufgeführt. Auch da halte
Datenkollision nicht für ausgeschlossen.
keine Garantie
hauspapa
