Hat einer Lust Modbus RTU2 in seiner Software zu implementieren? Das würde dann statt der 3,5 Zeichen Zeit Nachrichtenabgrenzung ein Längenfeld im Messageheader übertragen?
:
Bearbeitet durch User
Matthias schrieb: > Das würde dann statt der 3,5 Zeichen Zeit Nachrichtenabgrenzung ein > Längenfeld im Messageheader übertragen? Die Datenlänge ist doch schon teil des RTU-Protokolls.
Rahul D. schrieb: > Matthias schrieb: >> Das würde dann statt der 3,5 Zeichen Zeit Nachrichtenabgrenzung ein >> Längenfeld im Messageheader übertragen? > > Die Datenlänge ist doch schon teil des RTU-Protokolls. Steht wo??
Matthias schrieb: > Steht wo?? In der Spec?! Ich weiß ja nicht, was du als Länge vorsieht, aber sowohl Register- als auch Coil-Zugriffe enthalten die Angabe der Nutzlast-Bytes.
Rahul D. schrieb: > Matthias schrieb: >> Steht wo?? > > In der Spec?! > Ich weiß ja nicht, was du als Länge vorsieht, aber sowohl Register- als > auch Coil-Zugriffe enthalten die Angabe der Nutzlast-Bytes. Ah okay, also nicht direkt im Protokoll, sondern in der Umsetzung. Ich hatte schon tagelang überlegt, wie ich das hinbekomme... "Im RTU-Modus wird der Sendebeginn durch eine Sendepause von mindestens der 3,5-fachen Zeichenlänge markiert. Ein Zeichen hat eine Länge von 11 Bit. Die Länge der Sendepause hängt somit von der Übertragungsgeschwindigkeit ab. Dies muss bei niedrigen Datenraten exakt eingehalten werden." - https://de.m.wikipedia.org/wiki/Modbus
Matthias schrieb: > Ein Zeichen hat eine Länge von 11 Bit 1 Startbit, 8 Datenbits und 2 Stoppbits...
Matthias schrieb: > Modbus RTU2 Und was soll das sein? Hast Du das irgendwo aufgeschnappt? Matthias schrieb: > Im RTU-Modus wird der Sendebeginn durch eine Sendepause von mindestens > der 3,5-fachen Zeichenlänge markiert. Betonung liegt auf mindestens. Man kann ohne irgendein Problem auch sehr viel mehr Zeit zwischen zwei Telegrammen verstreichen lassen.
Rahul D. schrieb: > Matthias schrieb: >> Ein Zeichen hat eine Länge von 11 Bit > 1 Startbit, 8 Datenbits und 2 Stoppbits... Ja, aber wenn ich jetzt die konkrete Implementation nicht kenne, schaffe ich keine Nachrichtenabgrenzung. Aber, wenn das kein Problem ist 🤓
Matthias schrieb: > Ja, aber wenn ich jetzt die konkrete Implementation nicht kenne, schaffe > ich keine Nachrichtenabgrenzung. > > Aber, wenn das kein Problem ist 🤓 Du sprichts in Rätseln. Entweder kannst du die Daten schon während des Empfangs parsen (und so die Länge bestimmen), oder du brauchst das Timeout.
Matthias schrieb: > Rahul D. schrieb: >> Matthias schrieb: >>> Ein Zeichen hat eine Länge von 11 Bit >> 1 Startbit, 8 Datenbits und 2 Stoppbits... > > Ja, aber wenn ich jetzt die konkrete Implementation nicht kenne, schaffe > ich keine Nachrichtenabgrenzung. Natürlich muss man die Specs aus Sicht eines Empfängers anders betrachten als aus Sicht eines Senders. Der Sender hat halt dafür zu sorgen, dass einerseits die 3,5 Zeichen Pause zwischen Nachrichten als Minimum garantiert sind, andererseits aber innerhalb einer Nachricht niemals eine Pause auftritt, die die Dauer dieser 3,5 Zeichen erreicht oder gar überschreitet. Der Empfänger hingegen hat einfach nur alles >=3,5 Zeichen als Abgrenzung zwischen Nachrichten zu betrachten. Aber dies hat doch nichts mit dem Thema deines Threads zu tun. Die Definition der Nachrichtenlänge im Header ist davon vollkommen unabhängig. Du begreifst einfach nicht die Grundlagen des Protokolldesigns. Diese Sache mit der Pause als Nachrichtenabgrenzung dient nämlich genau dazu, dem Empfänger zu ermöglichen, auch dann korrekt (zumindest mit Minimalschaden) zu reagieren, wenn er z.B. die Langenangabe nicht korrekt empfangen hat. Trifft er z.B. auf eine PAUSE, bevor er die aus der Längenangabe entnommene Anzahl Bytes empfangen hat, weiß er, dass das Paket wohl ungültig sein muss und kann es verwerfen. Genauso umgekehrt: hat er eine lt. Längenangabe komplette Nachricht empfangen, bekommt aber innerhalb der nächsten 3,5 Zeichen keine PAUSE, dann kann er ebenfalls das Paket als ungültig verwerfen. Sowas nennt man Protokoll-Redundanz und hilft enorm dabei, die Kommunikation auch unter widrigen Bedingungen bezüglich der Signalqualität am Leben zu erhalten.
Es gibt aber per Definition keine Längenangabe in Modbus RTU. Der Arduino hat, wenn man nicht nur die Zeit messen will, eine Auflösung von 40 Microsekunden. Damit kann ich keine 3,5 Zeichenpause messen, Punkt aus.
Matthias schrieb: > Der Arduino hat, wenn man nicht nur die Zeit messen will, eine Auflösung > von 40 Microsekunden. > > Damit kann ich keine 3,5 Zeichenpause messen, Punkt aus. Dafür nimmt man ja auch einen Timer (Triggern auf jedes empfange Byte; Überlauf ==> Frameende) Oder eine Lib: https://docs.arduino.cc/learn/communication/modbus/ (kenne ich nicht, da ich Modbus nicht auf dem Arduino nutze).
Das ist das Modbus RTU Protokoll. Dann kommen die Hersteller und sagen, wenn an meinem Eingang x Bytes ankommen, werden y Bytes zurückgeschickt. Das ist die Implementierung, welche umsetzbar ist. Daher der Vorschlag, z. B. wie bei PostgreSQL, eine Nachrichtenlänge mitzuschicken. Dann braucht man keinen kompletten TCP-Stack für eine sichere Kommunikation.
Matthias schrieb: > Dann kommen die Hersteller und sagen, wenn an meinem Eingang x Bytes > ankommen, werden y Bytes zurückgeschickt. Häh? Bei Modbus liefert der Sklave immer nur die Anzahl an Bytes zurück, die der Master anfragt oder eine Quittierung auf einen Schreibbefehl. Das Ding ist standardisiert. Wenn einer das was anderes mit macht, ist das kein Modbus mehr.
Rahul D. schrieb: > Matthias schrieb: >> Der Arduino hat, wenn man nicht nur die Zeit messen will, eine Auflösung >> von 40 Microsekunden. >> >> Damit kann ich keine 3,5 Zeichenpause messen, Punkt aus. > > Dafür nimmt man ja auch einen Timer (Triggern auf jedes empfange Byte; > Überlauf ==> Frameende) > Oder eine Lib: > https://docs.arduino.cc/learn/communication/modbus/ > > (kenne ich nicht, da ich Modbus nicht auf dem Arduino nutze). Wie triggern? Ich dachte man hat einen Interrupt und addiert dann einfach die bekannte Zeit zwischen den Interrupt auf? Oder gibt es bei den AVR sowas wie RDTSC?
Rahul D. schrieb: > Matthias schrieb: >> Dann kommen die Hersteller und sagen, wenn an meinem Eingang x Bytes >> ankommen, werden y Bytes zurückgeschickt. > > Häh? > Bei Modbus liefert der Sklave immer nur die Anzahl an Bytes zurück, die > der Master anfragt oder eine Quittierung auf einen Schreibbefehl. > > Das Ding ist standardisiert. Wenn einer das was anderes mit macht, ist > das kein Modbus mehr. Stimmt doch überhaupt nicht 🧐
Matthias schrieb: > Es gibt aber per Definition keine Längenangabe in Modbus RTU. Doch, natürlich. Bei allen üblichen Kommandos gibt es die. > Der Arduino hat, wenn man nicht nur die Zeit messen will, eine Auflösung > von 40 Microsekunden. Das kann ich nicht glauben. Und falls doch, wäre Arduino wohl die falsche Basis. > Damit kann ich keine 3,5 Zeichenpause messen, Punkt aus. DU kannst das vielleicht nicht. Schonmal was von Non-Blocking-IO und Interrupts gehört? Das geht auch auf Arduino-Basis. Führt aber natürlich dazu, dass der Komfort des standardmäßigen dümmlichen Polling verloren geht. Du musst es dann halt so umsetzen, wie es auch alle anderen auch machen, die nicht auf diese völlig nutzlose Arduino-Gülle aufsetzen.
https://www.postgresql.org/docs/current/protocol-message-formats.html Nach Funktion und vor Daten muss eine Längenangabe rein. https://de.m.wikipedia.org/wiki/Modbus#Modbus/RTU
Matthias schrieb: > Wie triggern? Ich dachte man hat einen Interrupt und addiert dann > einfach die bekannte Zeit zwischen den Interrupt auf? Für jedes komplett empfagene Byte liefert ein AVR (der vermutlich auf deinem Arduinoboard verbaut ist) einen RXC-Interrupt. In dessen ISR kann man kurz mal einen Timer zurücksetzen, der auslöst, sobald die 3,5 Zeichen lang nicht empfangen wurde. Zum Thema "Ich dachte.." fallen mir zwei Sprüch ein, die nicht ganz nett sind... Matthias schrieb: > Stimmt doch überhaupt nicht 🧐 Beweis' das Gegenteil.
Rahul D. schrieb: > Matthias schrieb: >> Wie triggern? Ich dachte man hat einen Interrupt und addiert dann >> einfach die bekannte Zeit zwischen den Interrupt auf? > Für jedes komplett empfagene Byte liefert ein AVR (der vermutlich auf > deinem Arduinoboard verbaut ist) einen RXC-Interrupt. > In dessen ISR kann man kurz mal einen Timer zurücksetzen, der auslöst, > sobald die 3,5 Zeichen lang nicht empfangen wurde. > Zum Thema "Ich dachte.." fallen mir zwei Sprüch ein, die nicht ganz nett > sind... > > Matthias schrieb: >> Stimmt doch überhaupt nicht 🧐 > > Beweis' das Gegenteil. Was für einen Timer? Das Teil hat keine Uhr... Also zumindest keine mit der Genauigkeit 👎
:
Bearbeitet durch User
Matthias schrieb: > Was für einen Timer? Das Teil hat keine Uhr... Freitag ist seit 2 Tagen vorbei... Hast du dir mal den Link angeugckt, den nich gepostet habe? Offensichtlich ja nicht. Arduino ist ganz nett für den (Wieder-) Einstieg, aber sobald es etwas ab vom Künstler-Maistream geht, MUSS man sich auch mal das Datenblatt des verbeuten Controllers antum (und vielleicht auch nicht nur den Wikipedia-Artikel lesen).
Rahul D. schrieb: > Matthias schrieb: >> Was für einen Timer? Das Teil hat keine Uhr... > > Freitag ist seit 2 Tagen vorbei... > Hast du dir mal den Link angeugckt, den nich gepostet habe? > Offensichtlich ja nicht. > > Arduino ist ganz nett für den (Wieder-) Einstieg, aber sobald es etwas > ab vom Künstler-Maistream geht, MUSS man sich auch mal das Datenblatt > des verbeuten Controllers antum (und vielleicht auch nicht nur den > Wikipedia-Artikel lesen). Der AVR2560 eignet sich doch mit seinen 4 UART perfekt, das kann ein Pi auch nicht besser...
Matthias schrieb: > Was für einen Timer? Das Teil hat keine Uhr... Praktisch jeder µC hat Timer. Und ganz sicher alle, für die es die Arduino-Umgebung gibt. Willst du trollen oder was soll dieser Quatsch? > Also zumindest keine mit der Genauigkeit 👎 Unsinn. Welche von Arduino unterstützte Hardware soll das denn sein?
Matthias schrieb: > Der AVR2560 eignet sich doch mit seinen 4 UART perfekt, das kann ein Pi > auch nicht besser... Und? Was soll dieser Satz aussagen? Mir ist sowohl der ATmega2560 (Das Ding, das auf dem gleichnamigen Arduino-Board verbaut ist) als auch Raspberry Pis bekannt.
Ich fasse mal die Specs für dich zusammen. Die Datenlänge ist im Modbus-Header im Function-Bereich des headers als Byte/Register Count dokumentiert. Die Header-Länge ist definiert, daher auch die Nachrichtenlänge. Dass kein explizites Length byte am anfang des headers steht tut dieser funktion keinen abbruch. Die Auswertung der Pause klappt mit jedem Mikrocontroller, der wenigstens einen Timer besitzt. Ich vermute, deiner kann das auch. Vielleicht ist der nicht passend von deiner Programmierumgebung voreingestellt, dann ist es deine aufgabe dies zu tun. Nur weil der native Systick nur x us auflösung hat, bedeutet das nicht, dass es keinen freien Timer gibt, der feiner auslöst. Zudem empfehle ich, einen (Protokoll-)Standart erst dann "verbessern" zu wollen, wenn man ihn verstanden hat, es performanceschwierigkeiten gibt UND kein besserer Protokollstandart existiert. Dein Problem scheint auch auf erkennung des Nachrichtenendes zu beruhen. Ich kann dir garantieren, ein anfängliches Lenght-byte würde da keineswegs helfen, da sich damit jeder Empfänger nach kleinsten übertragungsfehlern festfahren würde.
:
Bearbeitet durch User
Matthias schrieb: > Der Arduino hat, wenn man nicht nur die Zeit messen will, eine Auflösung > von 40 Microsekunden. > > Damit kann ich keine 3,5 Zeichenpause messen, Punkt aus. Mit welcher Baudrate meinst Du hier arbeiten zu müssen?
Ob S. schrieb: > Matthias schrieb: > >> Was für einen Timer? Das Teil hat keine Uhr... > > Praktisch jeder µC hat Timer. Und ganz sicher alle, für die es die > Arduino-Umgebung gibt. > > Willst du trollen oder was soll dieser Quatsch? > >> Also zumindest keine mit der Genauigkeit 👎 > > Unsinn. Welche von Arduino unterstützte Hardware soll das denn sein? "Think a little about your problem. A 16 MHz Arduino executes its fastest instructions in 62.5 ns." Das sind irgendwo so um 16 noop Instruktionen pro Mikrosekunde. D.h. wenn ich jetzt eine Mikrosekundenauflösung brauche, kann ich sonst nichts mehr machen, weil ein 64 Bit adder + Interrupt mindestens 16 Instruktionen braucht.
Matthias schrieb: > "Think a little about your problem. > A 16 MHz Arduino executes its fastest instructions in 62.5 ns." > > Das sind irgendwo so um 16 noop Instruktionen pro Mikrosekunde. > > D.h. wenn ich jetzt eine Mikrosekundenauflösung brauche, kann ich sonst > nichts mehr machen, weil ein 64 Bit adder + Interrupt mindestens 16 > Instruktionen braucht. Komisch, dass Modbus aus den 1970er oder so stammt. Damals hat man das schon hinbekommen, obwohl Mikrocontroller mit 1 oder 2 MHz liefen. Arduino passt nun mal nur bedingt für zeitkritische Anwendungen.
Rahul D. schrieb: > Matthias schrieb: >> "Think a little about your problem. >> A 16 MHz Arduino executes its fastest instructions in 62.5 ns." >> >> Das sind irgendwo so um 16 noop Instruktionen pro Mikrosekunde. >> >> D.h. wenn ich jetzt eine Mikrosekundenauflösung brauche, kann ich sonst >> nichts mehr machen, weil ein 64 Bit adder + Interrupt mindestens 16 >> Instruktionen braucht. > > Komisch, dass Modbus aus den 1970er oder so stammt. > Damals hat man das schon hinbekommen, obwohl Mikrocontroller mit 1 oder > 2 MHz liefen. > > Arduino passt nun mal nur bedingt für zeitkritische Anwendungen. Mein Modem in den späten 1990'er hatte halt 38.400 bit/s und damit war man schon weit vorne. Musst halt mit der Bitrate sehr weit runter 🤗
Matthias schrieb: > Mein Modem in den späten 1990'er hatte halt 38.400 bit/s und damit war > man schon weit vorne. > > Musst halt mit der Bitrate sehr weit runter 🤗 Und ich dachte, mein ADHS sei schlimm. Was hat das eine mit dem anderne zu tun? Wie gesagt: der Trollfreitag war vor zwei Tagen.
Das ist die Übertragungsgeschwindigkeit von 1970... https://de.m.wikipedia.org/wiki/Teletype_Modell_33 "Die Schreibleistung eines durchschnittlich schnellen 10-Finger-Schreibers liegt zwischen 200 und 400 Anschlägen je Minute. Bei nationalen Wettbewerben erreichen Spitzenschreiber Geschwindigkeiten von bis zu 750 Anschlägen pro Minute, bei internationalen auch bis zu 900 Anschläge (vgl. Tastschreiben)." Und ich kann dir sagen, dass die Geräte langsamer übertragen haben als man schreiben konnte 😋
So, mal aus der Praxis: Die meisten Implementation checken die 3.5 chars zwischen zwei Bytes innerhalb eines Paketes nicht. Das kannst Du also auch weglessen - damit befindest Du Dich in guter Gesellschaft. Das Protokoll selber darfst Du natürlich nicht ändern - kein Stück. Aber das ist auch gar nicht notwendig. Bei vielen Befehlen weißt Du schon nach dem zweiten Byte (1. Byte: Slave-Adresse, 2. Byte: Funktionscode), wie viele Bytes noch kommen. Bei Multi-Value Funktionen weißt Du spätestens 4 Bytes später die Länge des kompletten Paketes. Das ist also kein prinzipielles Problem - andere Leute schaffen das auch. fchk
Matthias schrieb: > "Think a little about your problem. > A 16 MHz Arduino executes its fastest instructions in 62.5 ns." > > Das sind irgendwo so um 16 noop Instruktionen pro Mikrosekunde. > > D.h. wenn ich jetzt eine Mikrosekundenauflösung brauche, kann ich sonst > nichts mehr machen, weil ein 64 Bit adder + Interrupt mindestens 16 > Instruktionen braucht. Das ist korrekt. Jeder vernünftige Mensch würde daraus den Schluss ziehen, dass es kompletter Schwachsinn wäre, diese Sache mit so etwas wie einem interruptgetrieben Systick zu behandeln. Dein Problem ist halt nur, dass genau das halt der normale Arduino-Weg ist und du nix anderes kennst... Musst du einfach mal dazu lernen. Du bist ein typisches Beispiel für jemanden, der heftig in die Arduino-Falle getappt ist.
Ob S. schrieb: > Matthias schrieb: >> Es gibt aber per Definition keine Längenangabe in Modbus RTU. > > Doch, natürlich. Bei allen üblichen Kommandos gibt es die. Jein. Die meisten Requests enthalten kein Längenfeld, welches explizit die Gesamtlänge des Pakets oder der Nutzdaten angibt. Bei einigen Requests muss man sich die Länge selbst z.B. anhand der Anzahl an Coils oder Registern ausrechnen, bei anderen gibt es das Feld "Quantity to Write", welches man auf die Headerlänger draufschlagen muss. Nur in den Responses gibt es immer das Feld "Byte Count", welches die Gesamtlänge der Nutzdaten angibt. Diese Asymmetrie ist unschön, aber nun mal gegeben. Richtig problematisch kann es werden, wenn einige Slave auch Pakete, die nicht an sie selbst adressiert sind, auf Korrektheit prüfen und dabei die Pause zwischen Request des Masters und Response eines anderen Slaves nicht erkennen. Und bei der nächsten Abfrage solch eines überpeniblen Slaves gibt es dann eine nur eine Fehlermeldung. So etwas hat uns mal eine mehrtägige Suche nach Kommunikationsproblemen mit einem bestimmten Gerätetyp beschert. Irgendwann fand ich dann heraus, dass man bei diesen Geräten erst einmal ein Konfigurationsregister beschreiben muss, in dem die Behandlung des o.a. Fehlers explizit unterbunden wird. Glücklicherweise lässt sich dieses Register nichtflüchtig speichern, so dass es nicht mehr zu diesem Fehlerbild kommen kann, während gerade diese Konfiguration stattfindet. Denn auch genau dieser Gerätetyp antwortet selbst auch so schnell auf Requests, dass die 3,5 Zeichen bzw. 1,75 ms nicht eingehalten werden. Nichtdestotrotz labert aber der TE natürlich mal wieder den allseits bekannten völligen Unsinn über Protokollstacks. Das kennen wir ja schon aus anderen Threads.
Harald K. schrieb: > Mit welcher Baudrate meinst Du hier arbeiten zu müssen? Der TE hat doch schon hier in seiner endlosen Weisheit verkündet, dass Modbus immer mit 19.200 Bit/s betrieben werde: Beitrag "Re: Grundsatzfrage zum Bustransfer"
Man könnte schon den Prescaler eines Timer auf 1 stellen, damit müsste ich auf 16 us pro Erhöhung kommen? Hat das schon mal einer probiert? Nicht, dass das dann unnötig die Nachrichten zerhackt, wenn man eh weiß was ankommen muss??
So, jetzt habt ihr erst mal wieder Ruhe, ich gehe ins Bett und schaufele morgen weiter. Nächstes WE vllt. wieder 😇
:
Bearbeitet durch User
Matthias schrieb: > So, jetzt habt ihr erst mal wieder Ruhe, ich gehe ins Bett und > schaufele > morgen weiter. Nächstes WE vllt. wieder 😇 Und lass den Cannabiskonsum, wenn du hier Fragen beantwortet haben willst.
Rahul D. schrieb: > Matthias schrieb: >> So, jetzt habt ihr erst mal wieder Ruhe, ich gehe ins Bett und >> schaufele >> morgen weiter. Nächstes WE vllt. wieder 😇 > > Und lass den Cannabiskonsum, wenn du hier Fragen beantwortet haben > willst. ?? Was soll denn die Unterstellung?
Matthias schrieb: > Der Arduino hat, wenn man nicht nur die Zeit messen will, eine Auflösung > von 40 Microsekunden. Arduino ist ein Framework, was auf dem Mikrocontroller AVR aufsetzt. Es belegt einige Ressourcen (z.B. Timer 0), alle anderen sind weiterhin frei verfügbar. Arduino ist quelloffen, d.h. Du kannst jederzeit eigene Erweiterungen hinzufügen. Matthias schrieb: > Damit kann ich keine 3,5 Zeichenpause messen, Punkt aus. Das ist eine Minimalangabe, mehr ist natürlich erlaubt. Der Sender kann z.B. minimal 4 Bytezeiten warten, der Empfänger kann alles größer 3 Bytezeiten als Sync betrachten. Genauer mußt Du nicht messen (und macht auch keiner). Und wie schon gesagt wurde, es gibt Timer und Interrupts. Du mußt die Zeiten also nicht in Software verwarten. Du kannst z.B. ein Compareregister eines Timers auf 3,5 Bytezeiten laden und wenn der nächste Empfangsinterrupt kommt, schaust Du einfach nach, ob das Compareflag gesetzt ist oder nicht. Du darfst sämtliche Ressourcen des Mikrocontrollers benutzen. Nur mußt Du dazu auch ins Datenblatt in die entsprechenden Abschnitte schauen. Ein guter Programmierer macht das auch.
:
Bearbeitet durch User
Peter D. schrieb: > Ein guter Programmierer macht das auch. Du hast den mit Salz verkrusteten Finger in die Wunde gesteckt ...
Es gibt sogar einen Haufen Microcontroller, zum Beispiel etliche aus der Baureihe STM32, deren integrierte U(S)ARTS einen speziellen Modbus-Modus haben und eigenständig die Empfangspause bestimmen und das ganze signalisieren können. Hierbei wird aber natürlich nicht genau gemessen, ob es wirklich 3,5000 oder vielleicht doch nur 3,493 Zeichenäquivalente waren, sondern alles ab 2 Zeichenäquivalenten als gültig anerkannt. Allerdings nutzen viele Modbus-Protokollstacks dieses Feature nicht aus, sondern verwenden eben die schon erwähnten Hardwaretimer, die so gar nichts mit einer Systemuhr zu tun haben.
Andreas S. schrieb: > Allerdings nutzen viele Modbus-Protokollstacks dieses Feature nicht aus, > sondern verwenden eben die schon erwähnten Hardwaretimer, die so gar > nichts mit einer Systemuhr zu tun haben. Das ist kein Protokollstack. Modbus RTU lässt sich nicht mit der Zeichenpause auf ein Teletype setzen. Selbst, wenn ich da den Timeout im Teletype habe, was mache ich dann mit den Daten im Speicher? Das lässt sich auch nicht sinnvoll mit select() abarbeiten? Da muss man in der Theorie nach jedem Timeout den Speicherbereich wechseln und das Nachrichtenbasiert an das Programm durchreichen. Zeichenbasiert ist da imho nichts zu machen...
Matthias schrieb: > Das ist kein Protokollstack. Modbus RTU lässt sich nicht mit der > Zeichenpause auf ein Teletype setzen. Bezahlt Dich irgendwer für den Quark, den Du da schreibst?
Harald K. schrieb: > Matthias schrieb: >> Das ist kein Protokollstack. Modbus RTU lässt sich nicht mit der >> Zeichenpause auf ein Teletype setzen. > > Bezahlt Dich irgendwer für den Quark, den Du da schreibst? Versuch es doch selbst mal... Und idealerweise zeigst du uns dann auch den Lösungsweg, damit das nicht nur Bla Bla ist 😤
:
Bearbeitet durch User
Matthias schrieb: > Versuch es doch selbst mal... Was soll ich versuchen? Besseren Quark zu schreiben als Du?
Zeig doch mal ein paar Zeilen Pseudocode, Modbus RTU mit Zeichenpause und select(). 💩
Matthias schrieb: > Zeig doch mal ein paar Zeilen Pseudocode, Modbus RTU mit Zeichenpause > und select(). Wieso select()? Was soll der Schwachsinn?
Matthias schrieb: > Hat einer Lust Modbus RTU2 in seiner Software zu implementieren? Nö. Matthias schrieb: > Es gibt aber per Definition keine Längenangabe in Modbus RTU. > Der Arduino hat, wenn man nicht nur die Zeit messen will, eine Auflösung > von 40 Microsekunden. > Damit kann ich keine 3,5 Zeichenpause messen, Punkt aus. Ja Kacke, dann kannst du halt nicht programmieren. Andere kriegen Modbus RTU umgesetzt. Warum also nur wegen deiner Programmierdefizite einen zweiten Standard erfinden ?
Michael B. schrieb: > Matthias schrieb: >> Hat einer Lust Modbus RTU2 in seiner Software zu implementieren? > > Nö. > > Matthias schrieb: >> Es gibt aber per Definition keine Längenangabe in Modbus RTU. >> Der Arduino hat, wenn man nicht nur die Zeit messen will, eine Auflösung >> von 40 Microsekunden. >> Damit kann ich keine 3,5 Zeichenpause messen, Punkt aus. > > Ja Kacke, dann kannst du halt nicht programmieren. > > Andere kriegen Modbus RTU umgesetzt. > > Warum also nur wegen deiner Programmierdefizite einen zweiten Standard > erfinden ? Der Huawei kann Modbus TCP und der Growatt mit modifizierter Firmware (https://github.com/mwalle/shinelanx-modbus). Modbus TCP behebt scheinbar das Problem, aber man braucht halt den kompletten TCP-Stack.
Matthias schrieb: > So sieht übrigens jeder > Protokollstapel aus der auf TCP/IP bzw UDP/IP aufsetzt. Hat nix mit modbus zu tun.
:
Bearbeitet durch User
Beitrag #7686606 wurde vom Autor gelöscht.
Klaus schrieb: > Hat nix mit modbus zu tun. Naja, "nix" ist nicht ganz richtig: Modbus geht auch über TCP/IP... Aber nicht per UART, sondern Ethernet. Matthias schrieb: > Modbus TCP behebt scheinbar das Problem, aber man braucht halt den > kompletten TCP-Stack. Wieso können eigentlich alle anderen, die sich mit Modbus-RTU auseinandersetzen müssen, dieses "Problem" beheben? Wenn dir das zu kompliziert ist, such dir einfach was einfacheres (z.B. Blümchen pflücken). Es liegt nicht am Modbus, sondern daran, dass du stur an irgendwas festhälst, was nicht einfach so mit dem Modbus umgehen kann ("Arduino in Reinform"). Ich hatte dir einen Link zu einer Modbus-Library für Arduino eingestellt. Da du bis jetzt nicht darauf eingegangen bist, hast du dich mit der Bibliothek offensichtlich nicht beschäftigt.
Matthias schrieb: > So sieht übrigens ein Protokollstapel aus. Ja. Und Modbus wurde im Jahre 1976 erfunden, und damals haben sich die Entwickler bei Modicon einfach nicht um das OSi-Schichtenmodell gekümmert. Das mag zwar unschön sein, ist aber für alle anderen außer Dir kein wirkliches Problem. fchk
Rahul D. schrieb: > Matthias schrieb: >> So sieht übrigens ein Protokollstapel aus. > > Modbus ist halt Layer 2... Nein, mit dem Zeitlimit Layer 1.
Rahul D. schrieb: > Klaus schrieb: >> Hat nix mit modbus zu tun. > > Naja, "nix" ist nicht ganz richtig: Modbus geht auch über TCP/IP... > Aber nicht per UART, sondern Ethernet. > Modbus TCP geht über UART und Ethernet. Keine Ahnung, was ihr da auf euren Mikrocontroller seit Jahrzehnten hinschlampt. "Protokollaufbau Transaktionsnummer Protokollkennzeichen Zahl der noch folgenden Bytes Adresse Funktion Daten 2 Byte 2 Byte (immer 0x0000) 2 Byte (n + 2) 1 Byte 1 Byte n Byte Dadurch, dass hier keine CRC-Prüfsummenbytes zu berechnen sind, ist die Implementierung eines Treibers für die TCP-Schnittstelle einfacher als für die serielle Schnittstelle, sofern man auf eine vorhandene TCP-Implementierung aufsetzen kann." - https://de.m.wikipedia.org/wiki/Modbus#Modbus/TCP
:
Bearbeitet durch User
Angehängte Dateien:
Zum Vergleich der TCP-Header und Modbus TCP-Payload.
Beitrag #7686793 wurde von einem Moderator gelöscht.
Modbus RTU ist eine Quälerei für die CPU durch die Zeichenorientierte Übertragung, nicht zu vergessen auch die Steuerung von Rx/Tx des Treibers bei Halbduplex. Bei TCP ist es effizienter weil sich die HW um das Bitgefriemel kümmert, Daten werden als Block geschickt/empfangen ohne die CPU für jedes Byte zu unterbrechen. Natürlich einen Controller mit ETH Interface vorausgesetzt, aber da gibt es heutzutage reichlichst. Für gemütliche Übertragung mit wenigen zig kB/s reicht Modbus RTU sicher oft genug auch, für schnelle Statusabfragen ist die serielle Varianten weniger gut.
Matthias schrieb: > Zum Vergleich der TCP-Header und Modbus TCP-Payload. Dass Du keine Ahnung hast wissen wir inzwischen alle, aber warum bekommst du deinen Schreibdurchfall nicht in Griff?
J. S. schrieb: > Modbus RTU ist eine Quälerei für die CPU durch die Zeichenorientierte > Übertragung, nicht zu vergessen auch die Steuerung von Rx/Tx des > Treibers bei Halbduplex. Bei TCP ist es effizienter weil sich die HW um > das Bitgefriemel kümmert, Daten werden als Block geschickt/empfangen > ohne die CPU für jedes Byte zu unterbrechen. Natürlich einen Controller > mit ETH Interface vorausgesetzt, aber da gibt es heutzutage reichlichst. > Für gemütliche Übertragung mit wenigen zig kB/s reicht Modbus RTU sicher > oft genug auch, für schnelle Statusabfragen ist die serielle Varianten > weniger gut. Das kann man so allgemein nicht sagen, kommt auf die Hardware drauf an. Die typischen STM32 UARTs z.B. können automatisch das RS485-driver-enable signal generieren, da die CPU bei Anfang/Ende des Telegrams aber so oder so etwas zu tun hat ist es auch kein großer Zusatzaufwand einen GPIO pin zu togglen. Weiters können besagte UARTS DMA Transfers und können nach Ablauf einer einstellbaren Frist in der nichts empfangen wird einen Interrupt generieren, damit spart man sich das manuelle mit-tracken der Timeouts. Eine einfache Implementierung die erst nach Ablauf der Timeouts ein komplettes Telegram verdaut und alles per DMA transferiert kommt mit zwei Interrupts pro Request/Response aus. Baudraten bis 2,5mps und 10k Pakete pro Sekunde sind damit kein Problem auf einem kleinen STM32F0.
J. S. schrieb: > Bei TCP ist es effizienter weil sich die HW um > das Bitgefriemel kümmert Ah ja, die TCP hardware im Arduino / AVR, wer kennt sie nicht. Wie schon häufiger geschrieben, hat der µC entweder USART mit nativer Modbus unterstützung, oder nicht. Und wenn der Computer eine dedizierte Netzwerkkarte hat, dann vielleicht auch TCP in "hardware". Falls nein, passiert das eben in einem Software-stack, aber für einen modernen Programmierer ist das alles "Schwarze Magie" die man unmöglich selbst programmieren kann. Programmieren können ist halt mehr, als "ich will... " in das ChatGPT-Prompt einzugeben
:
Bearbeitet durch User
Dumm daher reden und sich trotzdem teuer verkaufen ist auch eine Kunst.
Der AVR hat auch kein DMA. Und es gibt genügend Arduinos mit STM32 oder anderen 32 Bittern, auch mit Ethernet. Allerdings ist die Modbus RTU Implementierung selbst auf der Portenta Machine Control bescheiden.
Kinder, das führt zu nichts. Wenn es offensichtlich zu schwer ist, das fehlerfrei zu implementieren, sollte man es lieber gleich bleiben lassen. Für so einen Blödsinn ist mir meine Zeit zu schade!
Matthias schrieb: > Kinder, das führt zu nichts. Wenn es offensichtlich zu schwer ist, > das fehlerfrei zu implementieren Für dich. > sollte man es lieber gleich bleiben > lassen. Also lass es. > Für so einen Blödsinn ist mir meine Zeit zu schade! Genau, der Blödsinn ein inkompatibles Protokoll neu zu erfinden bloss weil man zu blöd ist, das programmieren zu können, was andere seit 48 Jahren erfolgreich schaffen. Eine timeout braucht man sowieso und immer, um Kommunikationsfehler erkennen zu können ohne die ganze Kiste zu blockieren.
:
Bearbeitet durch User
Angehängte Dateien:
Easy going...
Matthias schrieb: > Kinder, das führt zu nichts. Wenn es offensichtlich zu schwer ist, das > fehlerfrei zu implementieren, sollte man es lieber gleich bleiben > lassen. > > Für so einen Blödsinn ist mir meine Zeit zu schade! Die wirklichen Fehler (eher Versäumnisse) am modbus-Protokoll sind nicht ein fehlendes Längenfeld in der RTU Variante (welches so explizit auch nicht benötigt wird) sondern Dinge wie big endian byte order (da könnte man noch streiten, aber heute populäre Architekturen sind alle little endian), vor allem aber fehlende Fliesskommazahlen und andere Ganzzahlentypen als vorzeichenbehaftet 16bit. Sicher gibts da immer Workarounds, in der freien Wildbahn scheint aber jede mögliche Kombination vorzukommen wie man z.B 32 Bit floats in 2 16 Bit Register packt, schön ist das nicht.
Matthias schrieb: > Modbus TCP geht über UART und Ethernet. Keine Ahnung, was ihr da auf > euren Mikrocontroller seit Jahrzehnten hinschlampt. Wir machen das noch nicht sooo lange (keine 10 Jahre), dafür funktioniert es aber ziemlich gut. Robert M. schrieb: > Das kann man so allgemein nicht sagen, kommt auf die Hardware drauf an. > Die typischen STM32 UARTs z.B. können automatisch das > RS485-driver-enable signal generieren, da die CPU bei Anfang/Ende des > Telegrams aber so oder so etwas zu tun hat ist es auch kein großer > Zusatzaufwand einen GPIO pin zu togglen. Teilweise sind die sogar schon richtig Modbus-RTU-kompatibel, indem man die Timeoutlänge angeben kann. Naja, ich habe es hinbekommen. Damit ist für diese "Diskussion" beendet.
Robert M. schrieb: > Die wirklichen Fehler (eher Versäumnisse) am modbus-Protokoll sind nicht > ein fehlendes Längenfeld in der RTU Variante (welches so explizit auch > nicht benötigt wird) sondern Dinge wie big endian byte order (da könnte > man noch streiten, aber heute populäre Architekturen sind alle little > endian), Bei der Gelegenheit könnten wir dann auch gleich die Endianess in den Headern von TCP/IP glattziehen. > vor allem aber fehlende Fliesskommazahlen und andere > Ganzzahlentypen als vorzeichenbehaftet 16bit. Sicher gibts da immer > Workarounds, in der freien Wildbahn scheint aber jede mögliche > Kombination vorzukommen wie man z.B 32 Bit floats in 2 16 Bit Register > packt, schön ist das nicht. Wahrscheinlich ist es mittlerweile viel zu spät, um dort noch korrigierend eingreifen zu können, da es Unmenge an Bestandsgeräten gibt, die auf den o.a. Workarounds basieren. Das wäre vermutlich ähnlich erfolgversprechend wie die Vereinheitlichung der Aderfarben in Elektroinstallation, Schaltschrankbau un Elektronik.
Ein neuer Wechselrichter ist kein Bestandsgerät. Da muss der Hersteller die alte Scheiße nicht zwingend einsetzen.
Matthias schrieb: > Ein neuer Wechselrichter ist kein Bestandsgerät. Da muss der > Hersteller > die alte Scheiße nicht zwingend einsetzen. Aber vielleicht will der eine oder andere das Ding an einem vorhanden Gerät als Ersatz betreiben. Alle anderen sind natürlich daran schuld, dass du das nicht hinbekommst.
Matthias schrieb: > Ein neuer Wechselrichter ist kein Bestandsgerät. Da muss der Hersteller > die alte Scheiße nicht zwingend einsetzen. Hast Du das dem Hersteller schon erzählt? Und was sagt er dazu?
Rahul D. schrieb: > Aber vielleicht will der eine oder andere das Ding an einem vorhanden > Gerät als Ersatz betreiben. Wird schwierig bei dem nicht-vorhanden Kommando- und Registerbelegungsstandard.
Michael B. schrieb: > Rahul D. schrieb: >> Aber vielleicht will der eine oder andere das Ding an einem vorhanden >> Gerät als Ersatz betreiben. > > Wird schwierig bei dem nicht-vorhanden Kommando- und > Registerbelegungsstandard. Wer sagt, dass der Käufer des Ersatzteils das nicht weiß? Manche Hersteller liefern Geräte mit derselben oder einer erweiterten Registerbelegung aus. Die werden u.U. auch nicht immer alles (Teststände, andere Prüfmittel etc.) für eine Neuentwicklung über den Haufen werfen. "Aufwärtskompatibilität" nennt man sowas meines Wissen nach. Wenn man einem Modbus-Gerät einen nicht unterstützten Funktionscode oder eine nicht verfügbare Adresse liefert, sollte es im Regelfall eine Exception zurückliefern; Oder es passiert gar nichts. Die Registerbelegung kann natürlich geheim sein, wenn man seine Geräte nur innerhalb der eigenen System zulassen will.
Ganz ehrlich, mir ist es wurscht. Ich mache nach der Solaranlagensteuerung mit höchster Wahrscheinlichkeit eh nichts mehr mit Modbus. Meine Programmierkarriere ist am ausklingen und ich mache höchstens noch das fertig, was ich angefangen habe. Und dann arbeiten, wenn sich damit Geld verdienen lässt, andere an der Software weiter, oder eben nicht. So einfach ist das...
Beitrag #7687773 wurde von einem Moderator gelöscht.
Matthias schrieb: > nd ich mache höchstens noch > das fertig, was ich angefangen habe. Dann wird's hier ja in 5,6 Jahren endlich ruhiger.
Andreas S. schrieb: > Matthias schrieb: >> Meine Programmierkarriere ist am ausklingen > > Das ist ein sehr guter Entschluss. Danke, der Entschluss ist schon etwas älter. Ich habe dann umgeschult zu Immobilien 😂
Matthias schrieb: > Meine Programmierkarriere ist am ausklingen So würde ich das auch einschätzen. Du hast eindeutig andere Primärqualifikationen.
Harald K. schrieb: > Matthias schrieb: >> Meine Programmierkarriere ist am ausklingen > > So würde ich das auch einschätzen. Du hast eindeutig andere > Primärqualifikationen. Nee, ich bin einfach schon zu alt und habe keine große Lust mehr mich 12 Stunden am Tag vor den Bildschirm zu kleben, oder behelfsweise zwischenzeitlich Haltungsfehlstellungen auf dem Laufband zu therapieren... https://youtu.be/jYUZAF3ePFE
Matthias schrieb: > ich bin einfach schon zu alt und habe keine große Lust mehr mich 12 > Stunden am Tag vor den Bildschirm zu kleben Aber für's Forum reicht's doch auch...
Matthias schrieb: > habe keine große Lust mehr mich 12 Stunden am Tag vor den Bildschirm zu > kleben Warum tust du es dann trotzdem und postest am laufenden Meter unnütze YT-Filmchen? Ein Hinweis: wenn du so weitermachst musst du dir einen neuen Usernamen ausdenken.
Lothar M. schrieb: > Matthias schrieb: >> habe keine große Lust mehr mich 12 Stunden am Tag vor den Bildschirm zu >> kleben > Warum tust du es dann trotzdem und postest am laufenden Meter unnütze > YT-Filmchen? > > Ein Hinweis: wenn du so weitermachst musst du dir einen neuen Usernamen > ausdenken. Nö, müssen nicht. Übrigens ist ja eh alles geklärt, oder nicht? Das Modbus-Protokoll bleibt wie es ist, ich programmiere nur noch für mich zum Spaß und du moderierst bis zum Lebensende hier weiter...
Matthias schrieb: > Übrigens ist ja eh alles geklärt, oder nicht? Du hast hier doch eine Frage gestellt. Dann solltest du auch in der Lage sein, sie als beantwortet zu bewerten.
Soo nun lockern wir uns mal wieder auf.
Mit deutscher Grammatik:
Wie heisst die Zeitform in diesem Satz?
>> Der Bus kam heute pünktlich. <<
-Buskamperfekt
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.