Tach. Ich plane gerade ein System, bei dem es einen Master und mehrere Slaves geben wird, die per RS485 miteinander verbunden sind. Jetzt könnte ich mir natürlich ein eigenes Protokoll zwischen den einzelnen Knoten ausdenken. Ich muss das Rad aber nicht neu erfinden und verwende gverne auch etwas etabliertes, fertiges. Außer Modbus-RTU fällt mir aber kein Industrie-Standard-Protokoll ein. Profibus-DP kann auch RS485 als Physical Level benutzen, aber ich bin mir hier nicht sicher, ob das nicht spezielle Hardware braucht. Was gibt es außer Modbus noch so, was nur einen normalen UART benötigt. fchk
Frank K. schrieb: > Außer Modbus-RTU fällt > mir aber kein Industrie-Standard-Protokoll ein. Modbus/ASCII, das ist nicht so timingkritisch, aber ineffizienter. DMX512 mit RDM, wenn man das als Industrieprotokoll bezeichnen will.
Einen Standard nutzen ist sehr gut. Nur sollte da auch was für Dich abfallen: COTS-Geräte, Sniffer, Visualisierungssoftware, … Sonst hast Du einen riesigen Aufwand wegen z.b. Bitzeiten (Profibus) und keinen Vorteil.
Frank K. schrieb: > Außer Modbus-RTU fällt > mir aber kein Industrie-Standard-Protokoll ein. Es gäbe da noch BACnet, aber das ist ... ein sehr fetter Klops. Modbus ist einfach, für Modbus gibt es viele verfügbare Testwerkzeuge und Libraries. Bei Libraries und anderem Sourcecode muss man allerdings aufpassen, es gibt durchaus Leute, die Modbus nur teilweise oder nicht richtig verstanden haben, und ihre eher zufällig funktionierenden Ergebnisse stolz präsentieren. Eine der Stolperfallen ist die idiotische Registernummerierung, die redundant die Art des Registers in die Nummer eincodiert. Das Protokoll selbst weiß nichts davon, das adressiert alle Register mit einer 16-Bit-Adresse (0..65535), aber eine ganze Menge Leute lassen sich von dieser Nummerierungskonvention ins Bockshorn jagen. Eine andere ist, daß Modbus genau zwei Datentypen kennt: Bits und 16-Bit-Werte. Alles andere (z.B. Float) lässt sich zwar auch via Modbus übertragen, ist aber nicht Bestandteil der Spezifikation und wird von Hersteller zu Hersteller durchaus sehr unterschiedlich umgesetzt (unterschiedliche Wort- oder gar Byte-Reihenfolge, 32- oder 64-Bit-Float etc.) Statt irgendwelche überfrachteten und in mehreren Schichten abstrahierende Libraries zu nutzen, sollte man --wenigstens zum Einstieg-- selbst Modbus-Telegramme zusammenstellen und zerlegen können, damit man später das Knowhow hat, mit einem Mithörer eine Kommunikation zu analysieren, statt auf die oft irreführenden Fehlermeldung des x-ten Librarylayers zu hoffen.
Frank K. schrieb: > Ich plane gerade ein System, bei dem es einen Master und mehrere Slaves > geben wird, die per RS485 miteinander verbunden sind. Welche Datenmengen und wie oft möchtest Du denn übertragen? Wieviele Slaves sind denn angedacht? 2, 20 oder 200? Und gibt es was Zeitkritisches? Brauchst Du sowas wie Rundruf?
Ja, Baudrate, Leitungslaenge, Datenmenge, Sicherheit. Konfigurierung. Da spielen zu viele Details rein, fuer eine generelle Loesung. Fuer einen Master-Slave Bus wuerde ich RS422 bevorzugen, da gibt es einen gemeinsamen Rueckkanal und man muss nicht die Richtung Umschalten. Dieselben Leitungs Treiber. Uebrigens vergiss den DS75176, das sind Stromfresser, da gibt's welche die ziehen nur 0.5mA Eigenverbrauch
Modbus würde mir eigentlich reichen, dafür habe ich auch schon funktionierenden Code. Ich wollte nur sichedrgehen, dass ich nichts wesentliches übersehe. Und nein, keine Sorge wegen des DS75176. Der wirds nicht. Ich plane aktuell einen THVD1449 ein, was modernes also. fchk
Frank K. schrieb: > Ich plane gerade ein System, bei dem es einen Master und mehrere Slaves > geben wird, die per RS485 miteinander verbunden sind. Ich würde auf das deutlich bequemere CAN gehen. Da muß man sich nicht mit Kollisionen, Retry, CRC usw. abquälen, das erschlägt der CAN-Controller schon alles intern. Auch ist es kein Problem, wenn 2 Teilnehmer gleichzeitig senden. Einer gewinnt immer die Arbitration und der andere wiederholt automatisch sein Paket. Bei RS-485 sind dagegen beide Pakete zerstört.
Pandur S. schrieb: > Fuer einen Master-Slave Bus wuerde ich RS422 bevorzugen, da gibt es > einen gemeinsamen Rueckkanal und man muss nicht die Richtung Umschalten. Man muss aber vor dem Senden den Treiber für diesen Rückkanal ein- und danach wieder ausschalten, auf "Slave"-Seite jedenfalls, denn sonst blockieren sich die alle gegenseitig. Mit RS422 ist an dieser Stelle also wenig gewonnen, denn der Aufwand ist praktisch derselbe.
Peter D. schrieb: > Ich würde auf das deutlich bequemere CAN gehen. Das kann ein PC nicht ohne zusätzliche Hardware, noch nicht mal zu Diagnosezwecken mithören. Kollisionen sind bei einem Master-Slave-Protokoll kein Thema, die haben da nicht aufzutreten, da nie in Slave sendet, bevor er dazu aufgefordert wurde.
Harald K. schrieb: > Kollisionen sind bei einem Master-Slave-Protokoll kein Thema, die haben > da nicht aufzutreten, da nie in Slave sendet, bevor er dazu aufgefordert > wurde. Es ist aber äußerst bequem, wenn der Slave selber sagen kann, wann er fertig ist, Ereignisse eingetreten sind oder Daten verfügbar hat. Dann muß der Master nicht ständig pollen oder immer die maximale Zeit abwarten. RS-485 würde ich für neue Projekte nicht ohne große Not einsetzen. Eher würde ich schon auf CAN-FD Kompatibilität achten.
Peter D. schrieb: > Es ist aber äußerst bequem, wenn der Slave selber sagen kann, wann er > fertig ist, Ereignisse eingetreten sind oder Daten verfügbar hat. Das mag bequem sein, aber ist es nötig? Stört das Pollen des Masters? CAN mag da total viel besser und schicker sein, aber CAN kann man halt nicht mal eben mit 'nem PC und 'nem FT232 und angeschlossenem RS485-Treiber bespielen. Das zu können ist bei der Diagnose und Protokollanalyse aber sehr praktisch. Baut man sich ein eigenes Protokoll für RS485, kann man einen Anfragetelegrammtyp definieren, auf den ein angesprochener Slave entweder mit seinen angefallenen Daten reagiert oder aber auf das er "nö, alles OK, hab nix" meldet. Dann geht das Pollen auch bei meheren Slaves für sehr viele Anwendungen ausreichend schnell vonstattetn. Modbus kann so etwas von sich aus nicht, aber nichts spricht dagegen, sich da eine Protokollerweiterung drüberzustülpen - ein Register wird als "Änderungsflag" genutzt und zyklisch vom Master gepollt, und nur wenn dieses Flag gesetzt zurückkommt, fragt der Master den Rest ab und der Slave setzt in seinem Datenmodell das Flag zurück - solange, bis der Slave beim internen Herumrühren in seiner Suppe wieder was mitteilenswertes gefunden hat. Das ist nicht überkomplex und hilft, wenn man beide Enden der Kommunikation in der Hand hat, den Bus nicht zu überlasten. Und es ist trotzdem kompatibel zu anderer Modbus-Software, wie z.B. Modbus Poll.
alternating-bit-protokoll oder kurz altbit protokoll haben wir auf rs485 implementiert mit crc16 checksumme schlank und braucht kaum memory, cpu haelt sich in grenzen und ist eigentlich nur durch CRC rechnen gefordert. wir haben crc durch eine xor 1 byte checksumme ersetzt, so lief das selbst auf 8085 und seine varianten das adress feld 2 byte (1 bit broadcast 7 bit empfaenger/1 bit alternating, 7 bit sender) 1 byte message laenge, Xn message, 1 byte crc. der master pollt die slaves antworten nur wir hatten auch sowas wie interrupt message versucht, wo der slave selber in pausen loslegt, war aber nicht effektiv
Peter D. schrieb: > RS-485 würde ich für neue Projekte nicht ohne große Not einsetzen. > Eher würde ich schon auf CAN-FD Kompatibilität achten. Die Anwendungsfälle sind verschieden. CAN ist praktisch, weil das ganze Protokoll in Silizium gegossen ist. 485 ist (bei gleichem Leitungsaufwand) für deutlich längere Strecken. Beide haben gegenüber Daisychain den Nachteil, dass ein Busfehler überall sein kann. Da wir die Aufgabenstellung des TO so gar nicht kennen, kann CAN perfekt für ihn sein.
> Es ist aber äußerst bequem, wenn der Slave selber sagen kann, wann er > fertig ist, Ereignisse eingetreten sind oder Daten verfügbar hat. dann must die Kollisionen und das random retry Handeln, was dann schon ein erheblicher Software Aufwand ist und den zeitlichen Ablauf kraeftig beeinflussen kann.
> Pandur S. schrieb: > Fuer einen Master-Slave Bus wuerde ich RS422 bevorzugen, da gibt es > einen gemeinsamen Rueckkanal und man muss nicht die Richtung Umschalten. RS485 ist da kein Nachteil, man nimmt das TX signal verlaengert das Datensignal mit einem Monoflop um ein byte und steuert damit den rs485 Treiber ganz ohne Software aufwand Das selbe muss man auch bei rs422 machen mit dem Nachteil das der Treiber nicht mit einem 8 pol Chip realisiert werden kann, 4 Draehte braucht und auch vier Draehte gegen Spannungsspitzen geschutzt werden sollten. Auf den eingebauten überspannungsschutz der Treiber Chips wuerde ich mich nicht verlassen
> Da wir die Aufgabenstellung des TO so gar nicht kennen, kann CAN perfekt > für ihn sein. Ich zitiere den TO Was gibt es außer Modbus noch so, was nur einen normalen UART benötigt.
Roger S. schrieb: > dann must die Kollisionen und das random retry Handeln, ... Das heißt auf deutsch was?
Wenn die angeschlossenen Mikrocontroller dafür groß genug sind, würde ich textbasierte Protokolle vorziehen, die man mit einem Terminalprogramm debuggen kann.
Unbedingt, also Modbus ASCII. Einfacher wird ein Eigenbau auch nicht, nur anders. Alleine CRLF als Ende-Zeichen ist doch perfekt.
Roger S. schrieb: > RS485 ist da kein Nachteil, man nimmt das TX signal verlaengert das > Datensignal mit einem Monoflop um ein byte und steuert damit den rs485 > Treiber ganz ohne Software aufwand Oder man nimmt eine bessere UART. Die macht das in Hardware, schon die in den üblichen USB-UART-Bridges von FTDI verbauten UARTs können das. Andere UARTs können einen Interrupt auslösen, wenn das letzte Bit das Schieberegister verlassen hat. Ein Monoflop ist baudratenabhängig, wenn man sich sicher ist, nie mit anderen Baudraten konfrontiert zu sein, und das gut abgeglichen bekommt, dann kann das auch funktionieren.
Sherlock 🕵🏽♂️ schrieb: > Wenn die angeschlossenen Mikrocontroller dafür groß genug sind, würde > ich textbasierte Protokolle vorziehen, die man mit einem > Terminalprogramm debuggen kann. Vernünftige Terminalprogamme können serielle Daten selber z.B. in Hex darstellen. Oder willst du JSON-Romane über die Schnittstelle schicken, weil bei der Protokollfestlegung eigentlich noch gar nicht richtig feststeht, was an Inhalten übermittelt werden soll, oder weil die Daten so heterogen sind, dass man Klartext braucht, damit der Entwickler nicht überfordert wird oder man gar in die Dokumentation gucken muss, um mitlesen zu können? ;-)
Rainer W. schrieb: > Oder willst du JSON-Romane über die Schnittstelle schicken Ja, oder CSV oder irgendwas anderes mit Klartext. Aber nicht aus den von dir genannten Gründen. JSON macht vernünftige Planung nicht überflüssig. Ich bevorzuge Textbasierte Formate, weil man das wie gesagt mit bestehender Standardsoftware debuggen kann (nicht nur lesen, auch schreiben). Hex Dumps muss man sich in diesem Jahrhundert nicht mehr antun.
Sherlock 🕵🏽♂️ schrieb: > Hex Dumps muss man sich in diesem Jahrhundert nicht mehr > antun. Das kommt drauf an, was die Resource "Bandbreite" hergibt und wie die Busauslastung ist. Keiner käme - auch in diesem Jahrhundert - auf die Idee, mit Voyager in Klartext zu kommunizieren.
Rainer W. schrieb: > Keiner käme - auch in diesem Jahrhundert - auf die Idee, mit Voyager in > Klartext zu kommunizieren. Voyager wurde ja auch vor 50 Jahren gebaut. Heute hätte man XML :-) in EBCDIC.
Michael B. schrieb: > Voyager wurde ja auch vor 50 Jahren gebaut. > > Heute hätte man XML :-) > in EBCDIC. Dann leg schon einmal ein paar USD für eine eigene Antenne bereit. Es gibt auch noch andere, die Übertragungszeit beim DSN haben wollen. https://eyes.nasa.gov/apps/dsn-now/dsn.html
Sherlock 🕵🏽♂️ schrieb: > Wenn die angeschlossenen Mikrocontroller dafür groß genug sind, würde > ich textbasierte Protokolle vorziehen, die man mit einem > Terminalprogramm debuggen kann. Ich möchte (ohne dir zu widersprechen) für binäre Protokolle werben. Wenn man die Daten irgendwie auf den PC bekommt, kann man z.B. mit Python relativ einfach ein Programm schreiben, das die binären Daten interpretiert und Hex + Bedeutung auf einem Terminal ausgibt. Der Performance-Gewinn des binären Protokolls ist kein Argument. Mit Blick auf zukünftige Erweiterungen sollte es eh Reserve geben. Mein Hauptargument für binäre Protokolle ist die einfachere (und sicherere) Interpretation der Bedeutung. Mit Text-Protokollen ist man schnell dabei einen Parser zu bauen. Hier wurden historisch immer wieder Sicherheitslücken programmiert. Binäre Protokolle sind oft besser definiert und dichter. Damit meine ich, dass die Bedeutung jedes Bits bekannt ist und es weniger Varianten bei den Nachrichten gibt. Ich glaube, dass deswegen die Auswertung eines binären Protokolls, z.B. in C/C++, weniger anfällig für Programmierfehler ist. Es gibt also Argumente für beide Seiten. Für unsereins gilt das Argument natürlich nicht. Weil unser Code ist immer fehlerfrei ;-)
Tilo R. schrieb: > Mit Text-Protokollen ist man schnell dabei einen Parser zu bauen. Hier > wurden historisch immer wieder Sicherheitslücken programmiert. Programmiert man für binäre Protokolle nicht auch einen Parser?
Sherlock 🕵🏽♂️ schrieb: > Wenn die angeschlossenen Mikrocontroller dafür groß genug sind, würde > ich textbasierte Protokolle vorziehen, die man mit einem > Terminalprogramm debuggen kann. Wir sind auch zu Text gegangen (CAN), läßt sich leicht und sicher parsen. Binär ist einfach nur Müll.
Rahul D. schrieb: > Tilo R. schrieb: >> Mit Text-Protokollen ist man schnell dabei einen Parser zu bauen. Hier >> wurden historisch immer wieder Sicherheitslücken programmiert. > > Programmiert man für binäre Protokolle nicht auch einen Parser? Ja, aber das ist i.d. Regel eine Switch-artige Struktur, die hart auf (ggf. maskierten) Bytes arbeitet. Dort Varianten oder die Länge der Nachricht zu übersehen ist imho unwahrscheinlicher, als wenn man String-Compares machen muss.
Rahul D. schrieb: > Programmiert man für binäre Protokolle nicht auch einen Parser? Ein Beispiel: "Byte 5..8: 32Bit unsigned, Little Endian" ist eindeutig. Es gibt keinen mögliche abweichende Interpretation. Auch weil es keine Redundanz gibt.
Peter D. schrieb: > Wir sind auch zu Text gegangen (CAN), läßt sich leicht und sicher > parsen. Binär ist einfach nur Müll. Interessant. CAN hat ja nur 8 Datenbytes, wie habt ihr das mit längerem Text gelöst? Ein Byte als "Paketnummer" oder Continuation-Flag?
Bei CAN-FD sind mehr Nutzdaten möglich, ansonsten muss die Payload halt auf mehrere Telegramme verteilt 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.