Hallo,
ich habe hier eine openWB mit AZDelivery FT232 USB zu TTL RS485, EVSE WB (https://www.off-grid-systems.de/DIN-Simple-EVSE-WB-Wallbox-Bausatz) und einem Eastron SDM630.
Beides läuft auf 9600B und ich möchte es gern alle 2s abfragen, was auch grundsätzlich klappt.
Allerdings produziert die EVSE jede Minute bis jede Stunde Fehler.
Wenn ich die Abfrageintervalle auf 5 oder 10s reduziere, dann gibt es weniger Fehler.
Verbunden sind die drei mit normaler Leitung, also völlig ungeschirmt, keine GND angeschlossen, kein 120Ohm Widerstand.
Abfrage erfolgt in Node-Red über node-red-contrib-modbus 5.26.0.
Habe mit dem Queue Delay gespielt: 5,10,20,50ms - kein Erfolg.
Wenn ich nur den SDM630 abfrage, gibt es keine Fehler.
Wenn ich nur die EVSE abfrage weniger.
Wie würdet ihr vorgehen?
Geschirmte Telefonleitung mit GND ausprobieren ?
Generell 2x RS485 USB Adapter verwenden ?
oder zuerst 120Ohm Widerstand einbauen ?
Leitungslänge in der openWB sind vielleicht 30cm.
P.S.
Ich frage seit Jahren mehrere andere SDM72 über einen anderen RPi ab, hier gibt es überhaupt keine Probleme.
Allerdings verwende ich hier Telefonleitung mit GND und den teuren DSD TECH SH-U11F mit integriertem 120Ohm Widerstand.
Verbunden sind die drei mit normaler Leitung, also völlig ungeschirmt,
keine GND angeschlossen, kein 120Ohm Widerstand.
P.S.
Ich frage seit Jahren mehrere andere SDM72 über einen anderen RPi ab,
hier gibt es überhaupt keine Probleme.
Allerdings verwende ich hier Telefonleitung mit GND und den teuren DSD
TECH SH-U11F mit integriertem 120Ohm Widerstand.
MfG
Hallo,
du gibst dir selbst die Antwort. Terminierung und GND Bezugspotential. Verdrillte Leitungen sind auch normal.
Allerdings produziert die EVSE jede Minute bis jede Stunde Fehler.
Wenn ich die Abfrageintervalle auf 5 oder 10s reduziere, dann gibt es
weniger Fehler.
Erscheint logisch, denn wenn du nie abfragst, dann bekommst du gar keinen Fehler.
Geschirmte Telefonleitung mit GND ausprobieren ?
Ich würde erst mal gar nichts "probieren", sondern mit einem Oszilloskop "messen", ob die Pegel an den Pins der Bausteine passen. Und ob das Signal saubere Flanke und ungestörte Pegel hat. Und zwar würde ich das an den Anschlüssen beider Teilnehmer messen.
mit GND
Hast du derzeit keine definierte und klar geregelte GND-Verbindung zwischen den beiden Geräten? Denn per Definition braucht der RS485 eine GND-Verbindung (Stichwort Gleichtaktbereich der Empfängereingänge), wenn du nicht spezielle Koppler hast, die die Teilnehmer galvanisch isolieren.
Es gibt welche, die können das auch ohne GND, so wie es auch welche gibt, die im Lotto gewinnen:
Allerdings produziert die EVSE jede Minute bis jede Stunde Fehler.
Was für Fehler? Defekte Modbus-Telegramme (Parity-, Framing- oder CRC-Fehler), oder gibt das Ding definierte Modbus-Exceptions aus? Kann Deine Software so etwas auswerten?
Der RPi gibt nur raus:
Oct 16 17:42:10 openwb Node-RED[362]: 16 Oct 17:42:10 - [warn] [modbus-getter:1000 - 1003] Modbus Failure On State sending Get More About It By Logging
Oct 16 17:42:10 openwb Node-RED[362]: 16 Oct 17:42:10 - [warn] [modbus-getter:0000 - 0035] Modbus Failure On State sending Get More About It By Logging
Oct 16 17:42:10 openwb Node-RED[362]: 16 Oct 17:42:10 - [error] [modbus-getter:1000 - 1003] Error: Timed out
Oct 16 17:48:30 openwb Node-RED[362]: 16 Oct 17:48:30 - [warn] [modbus-getter:1000 - 1003] Modbus Failure On State sending Get More About It By Logging
Oct 16 17:48:30 openwb Node-RED[362]: 16 Oct 17:48:30 - [warn] [modbus-getter:0000 - 0035] Modbus Failure On State sending Get More About It By Logging
Oct 16 17:48:30 openwb Node-RED[362]: 16 Oct 17:48:30 - [error] [modbus-getter:1000 - 1003] Error: Timed out
Ein Oszilloskop besitze ich nicht.
Habe die Abfrage auf 5s gestellt, nun gibt es deutlich weniger Fehler.
Alle 1-2h.
Ich werde die Tage GND anschließen mit einem geschirmten Telefonkabel.
Ich werde die Tage GND anschließen mit einem geschirmten Telefonkabel.
Einfach mal mit einem Multimeter zwischen den beiden GNDs messen, ohne verbundene Datenleitungen. Wenn du da so ~120Volt Wechselspannung siehst, kommen die vom Entstörkondensator eines Schaltnetzteils. Die brechen bei Belastung sofort zusammen, d.H. die Schutzdioden in den RS485-Treibern biegen das schon wieder halbwegs passend hin. Schön ist es trotzdem nicht.
Auch DC messen, wir hatten hier vor einiger Zeit einen, bei dem sein Batteriewechselrichter das RS485-Potential auf Batterie-Plus hatte. Schöne Überraschung mit viel Rauch.
Kann man machen, wenn das System es zulässt. In dieser Beschreibung ist das offenbar so vorgesehen. Du musst deine Schaltung so auslegen, dass sie damit klarkommt.
Habe die Abfrage auf 5s gestellt, nun gibt es deutlich weniger Fehler.
Wenn ich ein solches System designe, dann muss es mit dauerhaftem Datenverkehr ein Wochenende lang ohne (seltsamen und mir unerklärlichen) Fehler laufen. Sonst bin ich noch nicht fertig.
Ein Oszilloskop besitze ich nicht.
Eine Inbetriebnahme (samt Fehlersuche) eines seriellen Busses ohne Oszilloskop ist wie "Autofahren nach Gehör": man sieht/hört immer erst hinterher, wenn es wieder nicht geklappt hat.
Der RPi gibt nur raus:
Oct 16 17:42:10 openwb Node-RED[362]: 16 Oct 17:42:10 - [warn]
[modbus-getter:1000 - 1003] Modbus Failure On State sending Get More
About It By Logging
Also das solltest du aendern. Es kann selbstverstaendlich sein das bei dir
noch was im Argen liegt das dir dann sofort auffaellt.
Allerdings es ist vollkommen normal das man bei einer Datenuebertragung
auch mal einen Fehler hat! Natuerlich eher selten! Aber in der
Praxis wird das immer mal wieder vorkommen und sei es nur wenn beim
Nachbarn der Blitz einschlaegt. Damit muss also eine Software klarkommen
und deshalb gibt es auch Pruefsummen.
Also erstmal die schlechte Software verbessern solange du noch viele
Fehler hast bis es trotzdem geht, danach dann die Hardware besser machen.
Ausserdem ist es sinnvoller die Fehler als x Fehler alle x Byte oder Datenpakete anzugeben und nicht in Minuten.
Allerdings produziert die EVSE jede Minute bis jede Stunde Fehler.
Die Aussage "Fehler" ist ziemlich nutzlos.
Du mußt die Fehler schon genau analysieren. Fehlen Bytes, werden Frame- oder Parity-Errors gemeldet, ist die CRC falsch, gibt es Kollisionen, sind die Daten Mumpitz usw.
Das kann man auch ganz ohne Oszi oder LA machen.
GND verbinden und den 120R anschließen sollte man auf jeden Fall machen.
Je öfter du Anfragen über den Bus stellst, desdo öfter wird es zu Kollisionen kommen, wenn ein Teilnehmer geschwätzig ist und ungefragt was rausposaunt
Je öfter du Anfragen über den Bus stellst, desdo öfter wird es zu
Kollisionen kommen, wenn ein Teilnehmer geschwätzig ist und ungefragt
was rausposaunt
Das kann es per Definition bei Modbus RTU nicht geben, denn da antwortet kein "Teilnehmer", ohne explizit gefragt worden zu sein.
Solange aber noch nicht mal das Logging der hier verwendeten Modbus-Library aktiviert wird, ist es müßig, sich den Kopf zu zerbrechen, was denn der "Fehler" ist.
Wie schon angedeutet: Modbus-Geräte können statt einer korrekten Antwort auch eine Exception zurückgeben, wenn sie beispielsweise gerade beschäftigt sind.
Das muss natürlich im vorliegenden Fall nicht sein, aber es ist eben alles andere als ausgeschlossen.
Wäre der RS485-Bus selbst gestört (durch falsche Abschlusswiderstände, Verdrahtungsfehler etc.), dann würde er nicht so gut und zuverlässig funktionieren, wie er es offenkundig tut.
Gibt es denn generell ein bestimmtes Abfrageintervall, was nicht unterschritten werden darf ?
Habe bei keinem Gerät dazu was gefunden.
Einen anderen SDM630 lese ich z.B. sekündlich aus, allerdings ist dieser alleine am Bus und mit 38,7kBaud.
Generell hatte ich z.B. Probleme wo ich den SDM630 mit 3x SDM72v2 an einem Bus hatte. Nun sind die 3x SDM72v2 an einem RS485 USB Adapter und der SDM630 ebenfalls an einem eigenen USB Adapter, seit dem 0 Probleme.
EVSE ist ja ein komplett anderes Gerät als ein SDM.
Werde berichten, wenn ich weiteres ausprobiert habe, kann etwas dauern ;-)
Gibt es denn generell ein bestimmtes Abfrageintervall, was nicht
unterschritten werden darf ?
Zwischen zwei Telegrammen müssen mindestens 3.5 Bytezeiten verstreichen. Das ist das einzige, was im Standard steht. Bei 9600 Baud ist eine Bytezeit etwa eine Millisekunde.
Habe bei keinem Gerät dazu was gefunden.
Das definiert der Hersteller der Geräte ... oder er lässt es.
Wenn die Geräte den Standard brauchbar umsetzen, können sie (wie ich jetzt zum dritten Mal erwähne) entsprechende Fehler als sog. Exceptions zurückmelden. Die muss halt die Software entsprechend auswerten können.
Keine Ahnung, was die hier genutzte Library da anstellt.
Zwischen zwei Telegrammen müssen mindestens 3.5 Bytezeiten verstreichen.
Das ist das einzige, was im Standard steht. Bei 9600 Baud ist eine
Bytezeit etwa eine Millisekunde.
Kannst du mir die Rechnung erklären, komme da nicht drauf.
Also sind bei meinem Modbus 10Bit = 1 Byte.
Somit müssen 3,6ms Pause zwischen den Registern verstreichen, aufgerundet auf 5ms.
Bei 38700B wären es dann 1ms ?
Bei 19200B wären es dann 2ms ?
Wie ist es bei Modbus TCP, gibt es da auch eine Regel ?
Zum Thema: gestern abend habe ich einen 2. RS485 Adapter verbaut, dazu Telefonkabel (mit GND) und seit dem keine Fehler mehr. Also der SDM hat seinen eigenen Adapter und die EVSE.
Ob das GND damit zu tun hat weiß ich natürlich nicht.
Der RS485 Adapter hat intern schon 120 Ohm an A+B.
Auch bei dir sind 8 Bit ein Byte. Dazu kommen halt noch Start-, Stop und Parity-Bit.
Pro Byte mussen (mindestens) 11Bit übertragen werden wenn ein Parity-Bit dabei ist. Bei 2 Stopbits damit sogar 12Bit.
Zum Thema: gestern abend habe ich einen 2. RS485 Adapter verbaut, dazu
Telefonkabel (mit GND) und seit dem keine Fehler mehr.
Sowas kenne ich auch. Es gibt RS485-Geräte, die dulden keine weiteren Slaves neben sich. Es ist dann zwecklos, vom Hersteller funktionierende Firmware zu fordern. Wir setzen nun 8-fach RS485 zu Ethernet Konverter ein, d.h. jeder Slave kriegt seine eigene RS485.
Zunächst prüfen ob WIRKLICH nur ZWEI Abschlusswiderstände vorhanden
sind. bei einem oder drei sind Probleme vorprogrammiert.
Kann muss aber nicht.
Laut Spezifikation ist das zwar richtig, aber ich habe auch schon genau die genteilige Erfahrung gemacht.
Mit einer Terminierung funktioniert es ohne jegliche Störung und sobald ich am Leitungsende ebenfalls terminiere funktioniert es nicht mehr störungsfrei.
Ebenso sagt die Spezifikation das mit einer hohen Baudrate 115200 nur noch wenige Meter zuverlässig funktionieren, 12m oder so waren es glaube ich.
Auch hier habe ich die Erfahrung gemacht das dies selbst mit 100m und ohne Abschlussterminierung einwandfrei funktioniert.
Und die Schirmung hatte ich beim Testen auch noch nicht angeschlossen.
Warum das so ist habe ich dann aber nicht erforscht.
Stimmt, hat du recht.
Ich beschäftige mich noch nicht so lange mit dem Thema und bin anscheinend irgendwann mit den Leitungslängen und übertragungsraten durcheinander gekommen.
Dann ist auch klar warum es keine Probleme gibt.
Danke für den Hinweis :-)
