Hallo, ich brauch bitte mal kurz den Rat der BUS-Technik-Profis hier :) Und zwar will ich für ein aktuelles Projekt ein BUS-System basierend auf RS485 aufbauen. Am Bus hängen dann später so ca. um die 10 Teilenhmer oder so. Das sind zB. Aktoren (Schrittmotoren) und verschiedene Eingabegeräte (zB. Joystick, Poti usw.) Das Problem ist aber, dass die Teilnehmer untereinander kommunizieren sollen, RS485 aber kein Multi-Master unterstützt. Aus diesem Grund hab ich mir mal folgendes ausgedacht und ich würde gerne kurz hören, was ihr so darüber denkt. Es gibt einen Master, das wird später wahrscheinlich ein PC sein. Eine Kommunikation am Bus geht immer nur von diesem Master aus. Jeder Knoten hat eine RX-Queue und eine TX-Queue. Will nun der Knoten A ein Paket an Knoten B schicken, so legt er das Paket mit der Zieladresse in seine TX-Queue. Der Master kennt alle Knotenadressen und geht diese der Reihe nach durch und schickt jedem Knoten einen Befehl, woraufhin dieser ein Paket aus seiner TX-Queue verschicken darf. Der adressierte Knoten empfängt dieses Paket und legt es in seine RX-Queue. Danach bestätigt dieser dem Master den Empfang und der Master fährt mit dem nächsten Knoten fort. Wenn ein Knoten gerade nichts zu verschicken hat, schickt dieser einfach gleich eine Antwort zum Master zurück. Der Master stoppt natürlich auch die Zeit zwischen einer Sendeaufforderung und dem Erhalt der Bestätigung, damit sich das ganze nicht aufhängt. Soweit hört sich das ganz gut an. Die Frage ist aber, Wie schaut es mit den Zeiten aus? Der Bus soll nämlich zB. den Sollwert des Joysticks an einen Aktor übermitteln und den Istwert wieder zurück. Und das ganze mit mehreren Aktoren. Ich hab mal so ganz grob gerechnet: Der Bus läuft wahrscheinlich mit 115200 Baud. dh: 115200 bit/s = 14400 Bytes/s Dh. bei 10 Knoten könnte jeder so in etwa 1400 Bytes/s verschicken. Natürlich noch etwas weniger wegen den Senderequests des Masters. Ich hab das ganze im Moment mal mit einem Knoten aufgebaut, damit klappts ganz gut. Ich muss jetzt aber erst ein paar weitere Knoten bauen, um das weiter testen zu können, aber was meint ihr so dazu? Seht ihr irgendwo Probleme? Danke.
Daniel P. schrieb: > 115200 bit/s = 14400 Bytes/s Du hast Start- und Stopbits übersehen. Mit 115200 Baud lassen sich maximal 11520 Byte/s übertragen (8 Bit pro Byte, je ein Start- und Stopbit, keine Parität). > Das Problem ist aber, dass die Teilnehmer untereinander kommunizieren > sollen, RS485 aber kein Multi-Master unterstützt. Du könntest Dir das recht ähnliche CAN ansehen ...
Rufus Τ. F. schrieb: > Du hast Start- und Stopbits übersehen. Mit 115200 Baud lassen sich > maximal 11520 Byte/s übertragen (8 Bit pro Byte, je ein Start- und > Stopbit, keine Parität). Hmm. Stimmt, danke, die hab ich übersehen. Ja CAN hab ich mir auch schon angeschaut und auch mal versucht ein CAN Netzwetk aufzubauen. Das wollte aber nicht wirklich anständig laufen und hat sich dauernd aufgehängt, weshalb ich diese Idee dann wieder verworfen habe. Außerdem hab ich irgendwo mal gelesen, dass CAN nur für kleine Datenmengen ausgelegt ist und die Beschränkung auf 8 Byte Payload war mir auch ein Dorn im Auge.
Was Du beschrieben hast, gibt es so ähnlich natürlich schon und nennt sich: "Modbus". Wie meine Vorredner würde ich aber auch zu CAN tendieren. Erspart Dir ne Menge Master/Slave-Gefummel und die bereits vorhandene Fehlerbehandlung (Telegramm-Wiederholung) in den untersten beiden OSI-Schichten ist bereits eingebaut. Wenn CAN mal korrekt konfiguriert ist, läuft es sehr stabil. Welchen Prozessor willst Du denn nehmen?
Daniel P. schrieb: > Außerdem hab ich irgendwo mal gelesen, dass CAN nur für kleine > Datenmengen ausgelegt ist und die Beschränkung auf 8 Byte Payload war > mir auch ein Dorn im Auge. Du schreibst, das sei für "Aktoren (Schrittmotoren) und verschiedene Eingabegeräte (zB. Joystick, Poti usw.)". Dafür sind 8 Bytes plus ID doch völlig ausreichend. Allerdings habe ich in einer Anwendung auch schon hunderte KB Logdaten über CAN geschaufelt.
Hei, RS485 definiert ja nur die Hardware... Es gibt doch auch ein Multimasterprotokoll dafür?!? Falls das wirklich notwendig sein sollte. Hab jetzt aber keinen Link lauwarm parat, aber Google sollte das finden. Grüße, Tom
Hallo, grundsätzlich ist eine solche Steuerung mit Master möglich. Der Vorteil gegenüber CAn ist, dass du das Timing selbst in der Hand hast und Debugging mit jedem Terminalprogramm leicht möglich ist. Für CAN braucht es da immer noch etwas mehr Hard- und Software. Zur Berechnung der Datenraten und Cycletime solltest du noch einige Aspekte berücksichtigen. 1. Pro Byte werden normal Startbit + Datenbits(7/8)+ + Parität + Stoppbits(1 oder 2) übertragen. Je nachdem ob du mit /ohne Paritätsbit und 1 oder 2 Stopbits arbeitest, hast du 10...12 Bitzeiten für ein Datenbyte. 2. Nach dem Senden eines Befehls muß der Slave erst mal antworten. Wie lange das dauern soll, mußt du bestimmen, wenn du die Slaves selber programmierst. Falls ein Slave nicht antwortet, sollte ein Timeout abgewartet werden ( z.B. 1ms ). 3. Je nach verwendtem Protokoll hat man natürlich einige Byte Overhead durch Codes für Protokollbegin, Adresse, Befehle, Checksumme, Prokollende. Man muß also zusätzlich zu den eigentlichen Daten immer noch ca. 4...8 Bytes zusätzlich übertragen. 4. Nachdem ein Slave Daten gesendet hat, muß der BUS noch freigegeben werden. deshalb ist auch eine gute Idee, nach jedem gesendeten Datenpaket eine kleine Pause zwische zu schieben (mind. 2..3 Bitzeiten). Das ist auch vorteilhaft, wenn man mal mit einem Oszi die Daten analysieren will. Je nach Komplexität des Protokolls und Anzahl Datenbytes kann aber bei 115kBaud der Master eine Anfrage in ca. 1ms abschicken und ein Slave in ca. 1ms antworten. Wenn man dann noch ca. 0,5..ms für Pausen einrechnet, kann man 10 Slaves in ca. 25...30ms einmal reihum abfragen. Wenn du willst, kannst du das Protokoll aber auch sehr einfach halten und auch eine etwas propritäre Version entwickeln. Unbedingt zu empfehlen sind die folgenden Varianten nicht, bzw. nur, wenn es unbedingt nötig ist. Besser ist eine sauber strukturierte Lösung. Wenn der Master z.B. nur einmal einen Zyklus aktiviert und die Slaves dann reihum selbststädig antworten, nachdem sie das entsprechende Datenpaket des Vorgängers detektiert haben, sparst du dir jedesmal die Einzelanfrage des Masters. Dann kann ein Zyklus auch deutlich unter 20ms abgearbeitet werden. Noch schneller wird es, wenn die Slaves gar kein Protokoll verwenden, sondern nur die reinen Nutzdaten senden (z.B. 2Byte). Das geht aber nur, wenn die Slaves nach der Masteranfrage die gesendeten Bytes mitzählen. Der erste Slave würde sofort senden, der 2 nach den ersten 2 Bytes usw. Da kommst du auch Zykluszeiten bis unter 3..5 ms, vorausgesetzt, die Slaves senden schnell genug, wenn sie dran sind. Es gibt noch viele andere Möglichkeiten und Variationen. der Verweis auf MODBUS wurde ja schon gegeben. Gruß Öletronika
Das vorgestellte Projekt ist etwas ueberzogen fuer den Anfang. Zum einen Soll ein PC den Master spielen koennen, zum Anderen soll auch Multimaster unterstuetzt werden. Das bedeutet maximale Komplexitaet. Wird nie fertig und nie zuverlaessig laufen. Was man machen kann, sind konfigurationsgeschichten dem PC zu ueberlassen. Der spielt dann wie ein normaler Knoten am Multimaster Betrieb mit. Das Problem am Multimaster Netzwerk, speziell wenn es sehr heterogene Knoten enthaelt, ist die Ausfallbehandlung. Wie soll ein beliebiger Knoten reagieren, wenn sein Ansprechpartner keine Antwort mehr gibt. Was bedeutet das nun. Zurueck zur Default Position ? So muss man jedem Knoten eine eigene Fehlerbehandlung mitgeben. Und sobald es eine aenderung am Netzwerk gibt, alle Knoten diesbezueglich updaten. Meiner ansicht nach ein Alptraum. Alternativ ist ein Master-Slave Netzwerk einfacher zu konfigurieren, einfacher zu debuggen. Nur darf man natuerlich nicht den PC als Masterknoten verwenden. Der kann das nicht. Zu langsam. Und zieht zuviel Strom. Als Masterknoten, dem alle anderen als Slaves untergeordnet sind wuerde ich einen Controller verwenden, der das Wissen des Netzwerks enthaelt. Der weiss, Knoten-1 = Tuere 1, Knoten-2 = Licht 1, usw. Dann muss dieses Wissen nur auf diesem einen Kboten vorhanden sein. Dieser Masterknoten sammelt dann alle Nachrichten und verteilt sie wieder. Die Slaveknoten muessen so nur ihr Ding kennen, dh die dazu verwendeten Befehle. Ein neues Feature des Netzwerkes betrifft dann nur den Masterknoten. Ein Multiknoten Netzwerk enthaelt addressierbare Knoten. Die Schwierigkeit bei einem heterogenen, verteilen System ist die Zuweisung der Adressen. Das muss manuell ueber einen Masterknoten geschehen. Der neue Knoten meldet sich ueber eine broadcast, und stellt sich vor. Der Masterknoten macht dann die Zuweisung, erstens der Adressen und zweitens der Funktionalitaet, sodass die anderen den auch kennen. Ob der Master-Konfigurationsknoten auch den Netzwerk Master spielt, oder nicht ist eigentlich egal.
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.