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.
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.
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.
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.
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.
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.
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.
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
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 im Beitrag #7882470:
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
Wenn die angeschlossenen Mikrocontroller dafür groß genug sind, würde ich textbasierte Protokolle vorziehen, die man mit einem Terminalprogramm debuggen kann.
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.
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? ;-)
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.
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.
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
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 ;-)
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.
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.
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.
