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. MfG
Christian B. schrieb: > Wie würdet ihr vorgehen? Es akzeptieren. Viele MODBUS Geräte reagieren manchmal nicht, weil sie intern beschäftigt sind. Es muss kein physischer Übertragungsfehler sein.
Christian B. schrieb: > 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.
Christian B. schrieb: > 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: - Beitrag "Datenübertragung über >100m" Veit D. schrieb: > Verdrillte Leitungen sind auch normal. Verdrillte Leitungen sorgen dafür, dass sich eine eingekoppelte Gleichtaktstörung beim nächsten "Schlag" wieder aufhebt: - Beitrag "Re: Neo Pixel info" Wenn das bei 30cm aber schon Probleme macht, dann sind da gewaltig Störungen unterwegs.
:
Bearbeitet durch Moderator
Christian B. schrieb: > 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. http://evracing.cz/evse/evse-wallbox/evse-wb-din_latest.pdf Ist es richtig, dass GND = PE ist ?
Christian B. schrieb: > 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.
Εrnst B. schrieb: > Die brechen bei Belastung sofort zusammen, d.H. die Schutzdioden in den > RS485-Treibern biegen das schon wieder halbwegs passend hin. Es wird dabei einfach der Baustein ausserhalb seiner Absolute Maximum Ratings betrieben und gehofft, dass das gut geht. Christian B. schrieb: > Ist es richtig, dass GND = PE ist ? 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.
Christian B. schrieb: > 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 Da steht doch, was Du machen sollst: Get More About It By Logging
> Ein Oszilloskop besitze ich nicht.
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.
Vanye
Christian B. schrieb: > 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
Gerald B. schrieb: > 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.
Ok, ich versuche mich mal am loggen. 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 ;-)
Zunächst prüfen ob WIRKLICH nur ZWEI Abschlusswiderstände vorhanden sind. bei einem oder drei sind Probleme vorprogrammiert.
Christian B. schrieb: > 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. Rüdiger B. schrieb: > Zunächst prüfen ob WIRKLICH nur ZWEI Abschlusswiderstände vorhanden > sind. bei einem oder drei sind Probleme vorprogrammiert. Das sorgt aber nicht für nur sehr gelegentliche Fehler. Hundert Mal auslesen klappt, einmal nicht -- das kann nicht an Abschlusswiderständen liegen.
Ohne GND und ist noch stolz drauf, ich denk die Performance ist gut fuer so einen Ansatz ... weg mit dem Troll. Das Protokol muss halt Retries machen, deswegen wird jede Meldung ja quittiert.
Purzel H. schrieb: > Ohne GND und ist noch stolz drauf Das ist nicht die Fehlerursache. Purzel H. schrieb: > Das Protokol muss halt Retries machen, deswegen wird jede Meldung ja > quittiert. [ ] Du hast ansatzweise verstanden, was Modbus ist.
>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. Bei RS485 ist doch Baudrate = Bitrate. 9600Bit/s = 9,375Byte/s --> * 3,5 = 32,8125 Byte Pausenlänge = 30ms.
Christian B. schrieb: > 9600Bit/s = 9,375Byte/s Sind deine Bytes 1024 Bit breit? Bei den üblicheren 8 Bit plus Start- und Stopbit entsprchen 9600Bit/s 960Byte/s, also etwa 1ms pro Byte.
ich Dussel. Sorry war spät gestern. 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.
:
Bearbeitet durch User
Christian B. schrieb: > Also sind bei meinem Modbus 10Bit = 1 Byte. 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.
:
Bearbeitet durch User
Christian B. schrieb: > 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] Die Frau hat um 17:42 und 17:48 den Staubsauger angeworfen.
Christian B. schrieb: > 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.
Rüdiger B. schrieb: > 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.
Angehängte Dateien:
-
rs485.png
63 KB
Nah, bei ordentlicher Terminierung und einem ordentlichen Kabel liegt das Limit bei dieser Baudrate so bei so 1200 Metern. https://assets.maxlinear.com/web/documents/an-292.pdf
Max H. schrieb: > Nah, bei ordentlicher Terminierung und einem ordentlichen Kabel liegt > das Limit bei dieser Baudrate so bei so 1200 Metern. > > https://assets.maxlinear.com/web/documents/an-292.pdf 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 :-)
Danke für die Rückmeldungen. Die EVSE wirft immer noch alle 2-6h mal einen Fehler, aber nicht zu vergleichen mit den Fehlern wo die EVSE und der SDM an einem Bus hingen. Der Staubsauger ist übrigens nicht schuld. Heute Nacht z.B. um 3Uhr ein Fehler und dann wieder um 6Uhr.
Christian B. schrieb: > Die EVSE wirft immer noch alle 2-6h mal einen Fehler Da Du nicht wissen willst, was die Ursache ist, hast Du auch weiterhin nicht die Modbus-Daten aufgezeichnet, oder?
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.