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.
Abend, dann hast Du also 200 cs Leitungen verdrahtet? Quatsch oder?
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.
Um genau zu sein 208. Kein Quatsch. Aber über Schieberegister in 8 Gruppen gelöst. ;-)
Und das ist dann ein daumendickes Kabel, mit 200 select-Adern und 2 Busleitungen?? Oder 200 4polige, verschaltet als Kampfstern? edit: Antwort überschnitten.
:
Bearbeitet durch User
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.
In dem Moment, in dem Du Kollisionen zulässt, brauchst Du das volle Programm aus Prüfsumme und Acknowledge.
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
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.