Guten Abend, ich stehe gerade ein wenig auf dem Schlauch und zwar habe ich ein kleines RS485 full duplex netzwerk mit sensoren und aktoren aufgebaut. Es gibt einen zentralen Master. Jetzt benötige ich auf der Sendeleitung zum Master eine Aktivitätsanzeige ob der bus gerade belegt ist. Dazu wäre es ja logisch, dass jeder der senden will die ganze zeit empfängt und erst wenn eine gewisse zeit nichts empfangen wurde, dann senden. Jetzt habe ich das Problem, dass der sensor nur auf den bus senden kann, aber nicht lesen. Deswegen wäre meine Frage ob jemand eine Idee hätte ? Meine Idee wäre es über einen opamp zu regeln der als diffentialverstärker auf der AB leitung sitzt und überprüft ob der pegel über dem normal pegel liegt.
Zu diesem Problem gibt es zwei Ansaetze, mit einem eigenen Protokoll. Das CDMA/CS und das Token. Das CDMA ist das fruehere 10Base2 Ethernet auf Koax. Wenn nichts empfangen wird, wird eine zufaellige Zeit gewartet und dann gesendet. Wenn man nachher eine Kollision erkennt, wird wiederholt. .. Etwas chaotisch. Das Token ist ein Fähnchen das einer Station gehoert, und die darf senden. Wenn sie fertig ist wird das Faehnchen der naechsten Station uebergeben. Der interessante Vorgang ist das vergeben eines neuen Faehnchens, falls es mal verlogen geht.
Hört sich alles ziemlich vergallopiert an bei Geräten die nur Senden können. Entweder hast Du einen einzigen Busmaster der alle Aktionen auf dem Bus initiiert (die Slaves auffordert zu senden), oder einen Multimaster Bus bei dem relativ aufwendig darüber verhandelt wird wer denn gerade Master ist. Wenn jedes Gerät zu jeder Zeit entscheiden kann ob es senden will oder nicht brauchst Du eine recht aufwändige Kollisionserkennung und Auflösung. CAN macht das z.B. in 'Hardware'. Etwas ähnliches kann man auch mit RS485 machen, ist aber mühseelig. Über irgendwelche pegel auf 'Bus ist frei' zu spekulieren hilft nichts weil ein anderes Gerät zeitgleich auf die gleiche Idee kommen könnte. In jedem Fall mußt Du Kolisionen erkennen (Lesen was man schreibt + vergleich ob da extern jemand dran rummacht) und die Kollision auflösen (warte zufällige Zeit und versuche noch mal mit max. X Versuchen). Geräte die nur senden können sind da fehl am Platze. Wozu eigentlich der Mehraufwand einen RS422 (fullduplex) zu verkabeln statt einem guten alten RS485 mit anständigem Master Slave Protokoll ?
Hallo, > Marcel O. schrieb: > Es gibt einen zentralen Master. Jetzt benötige ich auf der Sendeleitung > zum Master eine Aktivitätsanzeige ob der bus gerade belegt ist. Dazu > wäre es ja logisch, dass jeder der senden will die ganze zeit empfängt > und erst wenn eine gewisse zeit nichts empfangen wurde, dann senden. wie oben schon erklärt, macht man das in Praxis anders. Nur der Master sollte festlegen, wann ein Slave senden darf. Dazu wäre es also notwendig, dass: 1) der Master regelmäßig reihum die Slaves abfragt, 2) alle Slaves ein Timing einhalten, in dem sie antworten dürfen, 3) klar gekennzeichnet ist, wann ein Slave fertig ist, 4) Timeouts definiert sind, damit es weiter geht, wenn Antworten von Slaves ausfallen, 5) möglichst eine Fehlerbehandlung stattfindet, wenn Daten nicht korrekt übertragen werden. Falls ich was vergessen habe, können andere das gern vervollständigen. Das ist es, was oben als Methode "Token" bezeichnet wurde. Natürlich muss das alles vom sogenannten "Protokoll" umgesetzt werden, das die reibungslose Kommunikation gewährleisten soll. Gruß Öletronika
:
Bearbeitet durch User
U. M. schrieb: > Das ist es, was oben als Methode "Token" bezeicnet wurde. Das ist m.E. noch mal was anderes. Das Token macht den Empfänger zum Herrscher über den Bus bis er es weitergibt. Geht das Token verloren muß irgendjemand das neu erzeugen weil der Bus sonst tot ist. In einem Master / Slave System regelt das alles der Master und muß auf niemanden Rücksicht nehmen. Der Slave hat sein zugewiesenes Zeitfenster und hat danach die Klappe zu halten. Der Slave muß nie Master Funktionalität übernehmen und kann viel einfacher gestrickt sein.
Hallo, ja gut. Haste recht, das mit dem Token ist in dem Zusammenhang Quatsch. > Michael K. schrieb: > Der Slave hat sein zugewiesenes Zeitfenster > und hat danach die Klappe zu halten. Das straffe Master-Slave Prinzip ist deshalb auch am einfachsten zu handeln an einem RS485-Bus. Gruß Öletronika
Marcel O. schrieb: > Jetzt habe ich das Problem, dass der sensor nur auf den bus senden kann, > aber nicht lesen. Deswegen wäre meine Frage ob jemand eine Idee hätte ? Wie sendet der Sensor, in welchen Zeitabstanden ? Falls das unregelmassige Zeitabstande sind, gleich den sensor weg- schmeissen, ansonsten die Pause zwischen den Meldungen nutzen.
Marc V. schrieb: > Falls das unregelmassige Zeitabstande sind, gleich den sensor weg- > schmeissen, ansonsten die Pause zwischen den Meldungen nutzen. Die Sensoren senden nur wenn sich der Zustand ändert, also in nicht gegelmässig und sonst gibt es eigentlich keine Kommunikation auf den bus. Michael K. schrieb: > Das Token macht den Empfänger zum Herrscher über den Bus bis er es > weitergibt. Von den Tokensystem habe ich schon gehört. Aber so muss ja jeder Client alle anderen kennen oder irre ich mich da ?
Nein, muss nicht. Die anderen haben eine hoehere ID, oder nicht. Die ID Vergabe ist auch ein Thema. Es kommt beim normalen Betrib jeweils der naechste mit der hoeheren ID. Tokenring ist was anderes. Da hat jeder einen, resp zei eingaenge und einen, resp zwei Ausgaenge. Die Teilnehmer sind hintereinander geschaltet. Der eine Ring geht links rum, der Backup ring geht rechts rum. Die Meldung wird jeweil so weit durch den Ring weitergeschoben, bis der Adressat sie bekommt. Der antworted in derselben Richtung. Wenn eine Station detektiert, dass sie die letzte ist, werden die Meldungen von da auf dem Backup Ring gegeben und gehen von da zurueck. Hat mit einem Toke eigentlich nichts zu tun.
Marcel O. schrieb: > ich stehe gerade ein wenig auf dem Schlauch und zwar habe ich ein > kleines RS485 full duplex netzwerk mit sensoren und aktoren aufgebaut. Marcel O. schrieb: > Die Sensoren senden nur wenn sich der Zustand ändert, also in nicht > gegelmässig und sonst gibt es eigentlich keine Kommunikation auf den > bus. Soviel ich weiss, geht full duplex mit 4 Leitungen. Was hindert dich daran, mit diesen 4 Leitungen 2 Netze aufzubauen ? -2 Leitungen fur TALKER (Sensoren) -2 Leitungen fur LISTENER (Aktoren) Falls Aktoren nur LISTENER und Sensoren nur TALKER sind: Hardware-RxD fur Sensoren Hardware-TxD fur Aktoren Falls Aktoren und Sensoren beides sind: Hardware-TxD, Software-RxD fur Aktoren Software-TxD, Hardware-RxD fur Sensoren. Aktoren: Master entscheidet wann etwas gesendet werden soll, erwartet evtl. eine Bestatigung, also Software-RxD und Hardware-TxD. Sensoren: Master weiss nicht wann er etwas empfangen soll, also Hardware-RxD - (am besten mit ISR), muss evtl. bestatigen, aber dafur reicht Software-TxD. Und das sollte ohne Probleme gehen.
Marcel O. schrieb: > Es gibt einen zentralen Master Offensichtlich nicht, sonst würde ja das Problem nicht existieren. Du bezeichnest das vielleicht fälschlicherweise als Master, aber der hat ja seine Slaves nicht im Griff. Marcel O. schrieb: > Jetzt habe ich das Problem, dass der Sensor nur auf den Bus senden kann, > aber nicht lesen Das ist wohl das grundlegende Problem, so ist der Sensor eigentlich nicht busfähig, sondern kann nur mit einer Punkt-zu-Punkt-Verbindung arbeiten, die er exklusiv belegt. Da müsste man mehr über den Sensor wissen, z.B. ob man ihn irgendwie am Senden hindern kann. Sonst könnte man einen Controller zwischenschalten, der die Daten vom Sensor empfängt und nur auf Anforderung weitergibt. Georg
Meine Daumenregel ist, RS485 nur mit Master/Slave zu verwenden und für Multimaster z.B. auf CAN zu gehen. Multimaster-RS485 ist zwar möglich, aber sehr viel aufwändiger bei Implementierung und insbesondere beim Test aller möglichen Szenarien. Bei CAN ist das alles schon fertig.
:
Bearbeitet durch User
Georg schrieb: > Das ist wohl das grundlegende Problem, so ist der Sensor eigentlich > nicht busfähig, sondern kann nur mit einer Punkt-zu-Punkt-Verbindung > arbeiten, die er exklusiv belegt. Da müsste man mehr über den Sensor > wissen, z.B. ob man ihn irgendwie am Senden hindern kann. Sonst könnte > man einen Controller zwischenschalten, der die Daten vom Sensor empfängt > und nur auf Anforderung weitergibt. Genau. A. K. schrieb: > Meine Daumenregel ist, RS485 nur mit Master/Slave zu verwenden und für > Multimaster z.B. auf CAN zu gehen. Multimaster-RS485 ist zwar möglich, > aber sehr viel aufwändiger bei Implementierung und insbesondere beim > Test aller möglichen Szenarien. Bei CAN ist das alles schon fertig. Nicht unbedingt. Wenn man 2 getrennte Pins fur RE und TE nimmt (oder RE dauernd auf low), ist es sogar einfacher als bei CAN. Beim senden wird RE auf 0 gesetzt, wenn etwas anderes empfangen als gesendet wurde, dann hat irgendein Busteilnehmer dazwischengefunkt. Mit fail-safe biasing funktionert das ohne Probleme.
:
Bearbeitet durch User
Ich denke auch, daß hier nur ein richtiges Protkoll hilft, z.B. so: - Ein Slave sendet seine Daten nur, wenn er vom Master gefragt wurde. - Damit der Master nicht ständig pollen muß, darf ein Slave ein "Interruptsignal" (ein Byte) senden, was den Master zur Nachfrage auffordert. - während ein anderer Slave Daten sendet, ist das "Interruptsignal" natürlich verboten. Wann ein anderer Slave Daten sendet, weiß der Slave, weil er die entsprechende Frage des Masters empfangen hat. - Kollisionen zwischen Interruptsignalen stören nicht. Der Master muß bei einem Interrupt sowieso alle Slaves abfragen; er weiß ja nicht, welcher es war. Das ist natürlich darauf optimiert, daß es nur selten Daten zu melden gibt, sonst könnte man sich den Aufwand mit dem Interrupt sparen und einfach regelmäßig alles pollen. Wenn es seltener etwas zu melden gibt (geringere Kollisionswahrscheinlichkeit), kann man das Interruptsignal aussagekräftiger machen, z.B. ein Byte Slave-Adresse + ein Byte Prüfsumme. Dann kann der Master gezielt die Datenquelle befragen. Die Prüfsumme muß so gewählt sein, daß eine Kollision garantiert erkannt wird; bei einer Kollision muß der Master eben wieder alle Slaves abfragen. Im Extremfall: Slave sendet sein Telegramm, wenn es etwas zu melden gibt. Wenn es heile ankommt (Prüfsumme): Glück gehabt. Sonst: Master fragt alle einzeln ab.
Marcel O. schrieb: > Jetzt habe ich das Problem, dass der sensor nur auf den bus senden kann, > aber nicht lesen. Das ist wohl ein grundlegendes Missverständnis. Der Sensor sendet seine Daten differentiell nach RS422/485, aber busfähig ist er nicht, wahrscheinlich schaltet er nicht mal den Treiber ab. Das ist üblich, z.B. auch bei Drehgebern, die senden auch ihre Signale über differentielle Leitungen wegen der Störsicherheit, aber das sind nichtmal serielle Daten, sondern Zählimpulse. Sowas an einen RS485-Bus anzuschliessen, bloss weil es RS422/485 heisst, ist schlichtweg ein Irrtum. Die Signale sind für Zählereingänge(!) mit RS422/485-Receivern. So ein Eingang wird für jeden Sensor extra gebraucht. Georg
Georg schrieb: > wahrscheinlich schaltet er nicht mal den Treiber ab. Doch den Treiber schalte ich nur beim senden ein. Ich habe auch keinen µC dahinter sondern nur ganz normale TLL-Logic bausteine. Nosnibor schrieb: > Wenn es seltener etwas zu melden gibt (geringere > Kollisionswahrscheinlichkeit), kann man das Interruptsignal > aussagekräftiger machen, z.B. ein Byte Slave-Adresse + ein Byte > Prüfsumme. Dann kann der Master gezielt die Datenquelle befragen. Die > Prüfsumme muß so gewählt sein, daß eine Kollision garantiert erkannt > wird; bei einer Kollision muß der Master eben wieder alle Slaves > abfragen. Werde ich so Probieren, eine addition aller (nutz-)bytes als Prüfsumme reicht da aber wahrscheinlich nicht, aber für den Anfang sollte es riechen denke ich
Das ist nicht möglich. Stell Dir vor, Du bist mit jemandem zusammen, der zwar sprechen kann, aber taub ist. Da nutzt auch das anbrüllen mit "halt die Klappe" nichts. Zugegeben, bei der Kommunikation von Mensch zu Mensch kann z.B. Höflichkeit helfen. Die gibt es aber zwischen elektronischen Komponenten nicht. Sorgst Du also dafür, dass Dein Gegenüber Deine Kauleiste sieht, so hilft das etwas – vorausgesetzt, die steht auch mal still. In die Elektronik übersetzt bedeutet das, Du musst einen zusätzlichen Weg, an Stelle des "optischen Rückkanals", schaffen. Ein 08/14 Mikrokontroller macht das für Dich. Fast alle "sprechen" seriell. Der Sensor wird an einen eigenen Eingang angeschlossen und kann da quatschen wann er will. Die Kommunikation erfolgt über die serielle Schnittstelle (wie auch immer). Die Winzlinge dafür kosten fast nix und brauchen nur wenig Platz. Fehlt ein zweiter, serieller Kanal, so gibt es praktisch für alle Kandidaten Softwareemulationen. Der nötige Zwischenspeicher ist auch immer vorhanden, da das Datenvolumen im Allgemeinen gering (höchstens ein paar Datensätze) ist. Übrigens: Steht Dein System bereits, so kann Dir auch eine Huckepacklösung helfen. Z.B. ein Arduino, sozusagen "vorgeschaltet", stellt Dir alles, was das Herz begeht zur Verfügung. Ist dann aber nicht mehr in der Abteilung: Klein & Preiswert (was auch immer man darunter versteht) zu finden.
Marcel O. schrieb: > Doch den Treiber schalte ich nur beim senden ein. Ich habe auch keinen > µC dahinter sondern nur ganz normale TLL-Logic bausteine. Du hast eine RS422 Uart Verbindung mit TTL Gattern aufgebaut ? Startbit, Datenbits, Stopbit, inkl. stabiler Baudrate ? Was passiert wenn der Sensor nur sendet wenn neue Daten da sind, der Empfänger die aber nicht richtig mitbekommt ? Wie fordert er neue Daten an wenn der Sender nur senden kann das aber auch nur einmal tut. Ich vermute gerade das wir etwas völlig unterschiedliches meinen wenn wir über RS485 bzw. RS422 Busse reden.
Angehängte Dateien:
-
Interface_3b.png
54 KB
Warum full duplex für Sensoren mit kleinen Datenmengen bzw die gar nicht am Bus hören können? Warum TTL Gatter wenn alles ein einziger microcontroller erledigt? -> Der uC Kann immer empfangen und er weis wenn am Bus etwas (nicht) übertragen wird (Im Master / Slave mode kann ihm das aber egal sein) -> Nach einem Timeout wäre es dann jedoch möglich dass ein Sender selbst von sich aus zu senden beginnt (Umbedingt bei jedem Slave ein etwas anderes Timeout verwenden z.b. Timeout=X+Adresse dennoch empfehle ich dass der "Master" im Intervall die einzelnen "Sensoren" abfragt) -> Die Atmel uC haben einen Hardware Multi-processor Communication Mode Das Hilft bei den Slaves nur auf "Adressen" Bytes zu reagieren Ideal für den Master/Slave Mode Hier meine Hardware Lösung für ein ähnliches Projekt: Die Schaltung dient als User Interface dass auf dem RS485 Bus hängt als "Slave" (Display für Ausgabe und 5 Tasten sowie Rotarry Switch als Eingabe) Für den BUS selbst sind nur ein ICs und drei Steuer/Datenleitungen notwendig (Einfacher geht es wohl kaum) Wird hier eine Eingabe betätigt kommen die Daten entweder sofort auf den Bus(mein Fall) oder nach ständiger Abfrage(je nach Programmierung ist hier dann beides möglich) (Die Schaltung ist nicht vollständig und soll nur als Orientierung dienen ich bitte zu entschuldigen dass ich als Hobbyprogrammierer Paint zum Zeichen verwende ;-)) Mit diesem Konzept ist es einfach zb 8 Digitale Eingänge am Microcontroller in einem Intervall vom Master abfragen zu lassen Desweiteren könnten Aktoren gesetzt werden
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.