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.

Hallo Miq1,

kann mich wieder dem Thema ein paar Tage widmen. Frage: Über "bias" und Notwendigkeit beim MAX485 wird ja viel geschrieben. Ebenfalls bzgl der Dimensionierung abhängig von der Anzahl der Teilnehmer und ob diese ebenfalls mit Widerständen bestückt sind. Teilweise ist zu lesen, dass für MAX485 keine bias Widerstände notwendig sind -> Failsafe?

Welche Empfehlung hast du bzgl. "bias" mit 2 Teilnehmern und der Verwendung von MAX485. Beim SDM630 weiss ich natürlich nicht, welcher RS485 Treiber verwendet wird?

Bei dem 485 Modul, siehe Bild oben werden je 20kOhm verwendet (A-R20k-3V3, B-R20k-GND)

Gruß Arduino4Fun

Meiner Erfahrung nach hängt viel von der Leitungslänge ab. Im Nahbereich bis 2-3m habe ich durchaus schon ohne jede Terminierung gut übertragen können, allerdings auch in störungsarmer Umgebung.
Bei 5V und längeren Leitungen benutze ich üblicherweise 2x4K7 gegen Vcc und GND und die obligatorischen 120 Ohm zwischen den Leitungen.
Abgeschirmte Signalkabel natürlich, Schirm nur einseitig angeschlossen. Und daisy chain-verkabelt, kein Stern. Im Schaltschrank gelegentlich auch mal ganz kurze Y-Verkabelung zu zwei Servern.
Ich vermeide inzwischen aber die Adapter mit RE/DE, die mit Autohalbduplex funktionieren einfach ohne Mucken.

Hi,
danke für die schnelle Antwort. Habe mir eine Platine für ein Hutschienengehäuse und meine Zwecke "designed" und gestern gelötet und aufgebaut - Basis ist ein Wemos ESP32 mini Board. Auf der Basisplatine befindet sich auch der MAX485 mit den Bestückplätzen für die bias und Abschlusswiderstände. Nachdem die letzten Bauteile montiert sind, werde ich das Modul beim SDM630 montieren. Programmierung erfolgt dann über OTA, Debugging wird etwas aufwändiger. Die Verbindundsleitung wind dann max. 20..30cm sein.

Gruß Adrunio4Fun

Kommt mir sehr bekannt vor!:wink:

Deine Platine ist deutlich professioneller als die in meinem Hutschienengehäuse, klingt aber sonst ähnlich. Ich habe zwar ein OLED-Display und zwei Taster drin, mache das meiste aber auch remote - wegen zwei Stockwerken Treppe dazwischen :rofl:

Hi Miq1,
hat zwar nichts mit dem eigentlichen Thema zu tun - Wie ist deine preferierte Methode zu Debuggen ohne seriellen Monitor?
Gruß Arduino4Fun

Ich habe eine Telnet-Streamklasse geschrieben, die ich wie Serial benutzen kann (bis zu einer definierbaren Puffergröße).

Kannst Du uns Deine Telnetvariante geben?

Meine Telnetvariante ist hier.

Gruß Tommy

Sicher. Allerdings erst morgen, ich bin schon im Bett! :laughing: