Fehlermeldung mit Modbus Library

E0 - Timeout. Da klappt nichts mehr :thinking:

Dann führt das INPUT_PULLUP scheinbar dazu, dass der Client nichts mehr hört. Mist. Wieder ausbauen, fürchte ich.

Mir gehen momentan etwas die Ideen aus. Es muss etwas mit dem Toggeln von RE/DE zu tun haben, denn bei Autohalfduplexadaptern passiert es nicht, und zusätzlich gibt es einen Zusammenhang mit dem verwendeten Server. Neben deinem Zähler kenne ich inzwischen einen weiteren Typ und einen Drucksensor von den beiden anderen Usern, bei denen das passiert. Der eine hat sich vorläufig damit beholfen, von empfangenen Paketen alle führenden 0-Bytes wegzufiltern, bevor er sie verarbeitet. Klappt bei dir nicht, weil das Byte isoliert kommt.

Hi Miq1,

danke für deine unermüdlichen Einsatz. Morgen muss ich den Zähler meinem Elektriker übergeben, so dass er ihn in der Garage anschließt. Dann wird das Erfassen der Daten und das Einbringen einer SW etwas komplizierter. Notebook per USB in Garage oder per OTA vom heimischen PC. Sollte irgendwie beides gehen...
Hauptsache mein ioBroker bekommt irgendwann Daten vom Zähler.

Nochmals Danke und Gruß Arduino4Fun

Hallo, wann schaltet RE/DE um??

Manche Modbusgeräte sind etwas träge in der Reaktion.

In meinen Bibliotheken schalte ich Re/De daher erst nach dem 3.5t um. Auch kann es sein das dass Gerät selbst beim Umschalten seines Transceiver diese Phänomen erzeugt.

Aufschluss könnte hier ein Osziloskop geben, bei dem man nur den Client-Transceiver mal auswertet (Server nicht angeschlossen).

Eine weitere Möglichkeit für dieses Herrenlose Byte könnte auch ein Echo sein.

Hast du die Möglichkeit deinen Versuchsaufbau mal an nem Oszi zu hängen?

Grüsse
Curiosity

1 Like

Hallo,

aktuell habe ich kein vernüftiges Oszi im Zugriff. Muss mich leider :innocent: für 14 Tage in den Urlaub abmelden. Werde das Thema danach weiter verfolgen.

Danke und Gruß Arduino4Fun

Schönen Urlaub!

Alles, was ich bisher gefunden habe, deutet auf Leitungsprobleme durch undefinierte Pegel hin. Wenn du wieder da bist, checke sicherheitshalber nochmal die Terminierung an beiden Enden.

Hi Miq1,

alles klar. Werde ich akribisch durchmessen und Rückmeldung geben.

Zur aktuellen Beschaltung (sofern sie auch so "tut") Terminierung mit 120Ohm auf dem 485 Adapter, sowie 20kOhm von B nach GND und 20 kOhm von A nach +3V3. Verdrilltes CAT Kabel zwischen den Devices und diskreter 120Ohm Widerstand an den Klemmen des SDM630 zwischen A und B.

So long Adruino4Fun

Hmm, RS485 soll ja eigentlich symmetrisch sein, aber ich kenne immer nur die umgekehrte Terminierung: A+ an GND und B- an Vcc. Und auch mit kleineren Widerstandswerten bei 3V3 - 4K7 sollten es schon tun.

Ich denke du hast recht, ich schau gleich mal in meine Entwicklungsdaten.

Symmetrisch ist RS485 aber nicht in dieser Hinsicht, das du die Pegel invers zum Signal anlegst macht auch Sinn, wenn du dir am Oszi die Flankenrichtungen mal ansiehst.

Aber bei der Betrachtung Vorsicht, kommt drauf an wo du die Flanken hinlappst, also nach oben oder unten (invertierte/normalisierte Betrachtung)

Also ich hab mir das angesehen, werde dir später mal nen Beispiel-Schaltplan bzgl. Der Widerstände schicken.

Zu den Nullen:
Ich habe es gestern geschafft 7 Bytes 0 zu erhalten.

Wie hab ich das gemacht:
Rx/Tx vertauscht und dann im Programm des ESP den UART invertiert aktiviert.
Ich muss das ganze mal mit dem Oszi nachvollziehen.

Der Slave hat ein korrektes Telegramm erhalten, am Sniffer sah ich auch die korrekte Antwort. Aber der read-buffer des UART beinhaltete laut Logging-Funktion deiner Lib nur 0en. Leider habe ich gestern zu sehr die eigentliche Aufgabe verfolgt und den echten RX-Buffer nicht gespiegelt um das Ergebnis zu sehen. Interessant war auch zu sehen das eine einzige Null immer dann möglich ist, wenn das Gerät antwortet aber der rtsPin nicht im Programm gesetzt ist. Hier kommt nicht immer ein Timeout, ab und an auch das berühmte 0er Byte.

Doch ist die Quintessenz: ich konnte es mit Software reproduzieren.

Ach andere Frage, ich bekomm die Bridge (Wifi to RTU) nicht ans laufen, die Generierten Anfragen am RTU sehen sehr eigenartig aus.

Hast du hier weitere Infos?

1 Like

Das ist zumindest ein Schritt weiter - danke für Deine Analyse!

Das UART-Handling in der arduino-esp32 ist schon immer problematisch für uns gewesen. Deswegen gibt es unter anderem auch die UARTinit-Funktion, in der das Interrupthandling geändert werden muss, damit MODBUS überhaupt funktioniert mit dem ESP32.

Die Liste der Issues ist lang auf Github. Jetzt deutet sich zumindest eine Änderung an: im Master-Branch ist jetzt das ESP-IDF-Handling für UART implementiert, statt es wie bisher neu zu erfinden. Wir beobachten das und werden es übernehmen,sobald es als stable gilt. Unsere Hoffnung ist, dass die Seltsamkeiten, die manche Nutzer erleben, dann verschwinden.

Die Bridge funktioniert zumindest bei mir gut, sie existiert sozusagen hauptsächlich, weil ich sie selber brauchte :wink:

Kannst du mal ein Log posten, in dem man die Probleme nachvollziehen kann?

Ok, die Frage, in diesem Fread oder eigenen( will den Thread des TO nicht kapern)

Gerne hier, oder als Issue auf Github für eModbus, wenn Du magst. Da dann aber besser in Englisch.