Modbus RTU Extension - Slave spannungslos oder abgehängt = Störung anderer Slave's

[Dani78]

Geschätzte Community

Das erste Mal stelle ich hier Fragen ein, bei welchen ich nicht weiter weiss. Das eine oder andere habe ich bereits gefunden, jedoch z.T. nicht als Antwort auf meine Frage(n). Bitte entschuldigt, z.T. könnten es evt. Grundlagen sein, welche mir beim Modbus RTU fehlen. Bei anderen bei mir aus der Praxis bekannten Bus oder busähnlichen Systemen kenne ich dieses Verhalten nicht.

An der Modbus RTU Extension befindet sich als Grundinstallation:
- 1 Wärmemengenmessung (Heizung)
- 1 Drehstromzähler
- 1 Netzanalysemessgerät (Überwachung Stromzuleitung Haus)
Dies lief mit der Verkabelung und den Busabschlusswiderständen ohne weitere Probleme.
Die Einstellung der Extension war hierfür 9600, 1, gerade, Timing auto - Sensoren: Onlinestatus überwachen, z.T. Validierung. Abfragezyklus 5s.

Miniserver Gen 1 - FW 12.2.12.1

Aufgrund einer Erweiterung mit zwei Wechselrichter musste die Parität neu ausgeschaltet werden (auf WR nicht änderbar). Die Busstruktur ist infolge der Gegebenheiten nicht gerade nach Lehrbuch ausgeführt.

1.) Spannungsloser Slave
Am Tag funktioniert das ganze wie es soll. Trennt sich jedoch der Netzwechselrichter vom Netz, ist der Slave nicht mehr erreichbar, der MS meldet dadurch Sensorfehler.

a.) Validierung auf Sensorebene wurde danach deaktiviert -> kein Sensorfehler mehr. Jedoch hat dies einen neuen Nachteil: Der zuletzt empfangene Wert (z.B. Produktionsleistung 25W) wird die ganze Nacht hinüber in der Statistik hinterlegt. Wird hier wieder die Sensorüberwachung mit der Validierung verwendet, wird zwar der Messwert auf 0 gesetzt, aber der Sensorfehler kommt wieder.
--> Gibt es hier eine Lösung, wie die Validierung des Sensorwertes ohne Fehlermeldung umgesetzt werden kann? Die übrigen Busteilnehmer sollen weiterhin überwacht bleiben.

b.) Timing: Ebenfalls "störte" der nicht mehr empfangsbereite Slave die anderen Teilnehmer am Bus. Von denen konnten meist keine Daten mehr empfangen werden. Von z.B. 10 Abfragen wurden nur jeweils 1 beantwortet. Die übrigen wurden mit Sensorfehler ausgegeben. Die Verkabelung wurde zum Versuch nach Lehrbuch provisorisch aufgebaut und erneut simuliert, jedoch ohne Erfolg. (als Ergänzung: der in der Nacht spannungslose WR ist am Ende des Buses an einer längeren Leitung (30m). Danach habe ich das Timing auf Manuell, Pause 0.05s, Timeout 0.5s eingestellt. Dies funktioniert soweit gut.
--> Ist dies ein generelles Modbus RTU Phänomen oder kommt dies von Loxone her? Bringt ein weiterer Busteilnehmer nach dem spannungslosen WR evt. etwas? Sind die gewählten Timing Einstellung erfahrungsgemäss im Rahmen oder was würdet ihr mir hier empfehlen? Ist es empfehlenswert das Timing auf Manuell eingestellt zu lassen oder kann das Problem auf eine andere Weise gelöst werden?

2.) abgehängter oder noch nicht angeschlossener Slave
Bereits bei der Vorbereitung der beiden neuen Wechselrichter (noch nicht am Bus angeschlossen) ist mir folgendes aufgefallen: sobald die beiden neuen Modbus Geräte (Wechselrichter) und dessen Sensoreingänge vorkonfiguriert und auf den MS geschrieben wurden, meldet der MS Sensorfehler anderer (jedoch nicht aller) Slaves. Eine provisorische Änderung an der Busverkabelung hat hier keine Änderung bewirkt. Das gleiche Verhalten zeigt der MS, wenn zu Versuchszwecken ein Slave vom Bus abgehängt wird.
--> Ist dies ein generelles Modbus RTU Phänomen/Grundlage Bus oder kommt dies von Loxone her? Kann dieses Problem gelöst werden? (Klar, im Normalfall, wenn die Anlage läuft, bleibt alles angeschlossen. Ich muss jedoch zu Versuchszwecken einen Slave auf ein anderes Steuergerät hängen, um dieses jeweils zu testen. Da nervt der Ausfall der übrigen Slaves, vorallem bei den hinterlegten Logiken und nicht zuletzt in der Statistik...

3.) Abfragezyklus min. 5s
gem. Informationen keine kürzeren Abfragezyklen bei Modbus RTU möglich (Loxoneeinschränkung).
--> Ist dies noch aktuell oder kann dies irgendwie mit der gegebenen Hardware "umgangen" werden? Ist dies bei Modbus TCP oder bei anderen an Loxone angeschlossenen "Bus oder busähnlichen Systemen" ebenfalls so?

Als Wechselrichterlösungsvorschlag wurde Modbus TCP erwähnt. Kann ich nötigenfalls (auch wenn widerwillig *g* ) umsetzen, um die übrigen Slaves in der Datenübertragung nicht zu beeinträchtigen. Die Validierung mit dem daraus folgenden Sensorfehler würde jedoch weiterhin bestehen bleiben?

Ich danke allen, welche sich die Mühe gemacht haben, den doch etwas längeren Text vorgenommen zu haben und bin auf den einen oder anderen Input gespannt.

Beste Grüsse
Daniel

[Dani78]

Hallo zusammen

Hat auch nach den Sommerferien noch keiner eine Idee?
Zwischenzeitlich Update auf FW 13.0.7.26
Timing infolge Verschlechterung des Datenerhaltes durch das Update von manuell auf auto gestellt. Überwachung deaktiviert.

Besten Dank

Daniel

[hismastersvoice]

Was heißt Verkabelung nicht nach Lehrbuch?

Die 5 Sekunden bei Modbus sind immer noch das Limit.

Beim lesen des Text war meine erste Idee eine extra Modbus Extension oder ein 200€ günstigeres Modbus RTU/TCP Gateway. https://amzn.eu/d/flMafkD
Da die WR eh TCP können kannst du dir das natürlich sparen.

Insbesondere da die WR wohl nachts in Standby gehen wird ggf der Bus kurzgeschlossen, oder zumindest ein starker Spannungsabfall erzeugt.


Leider hat du keine Hersteller / Typen der Geräte genannt, so ist es natürlich ungleich schwerer Tipps zu geben.

[Dani78]

Besten Dank für die Nachfrage.

Nicht nach Lehrbuch soll heissen, eher Stern- statt Bus- Struktur. Eine provisorische Verlegung der Kabel als Busstruktur hat jedoch keine Besserung gebracht.

Bezüglich der extra Modbus Extension oder eben auch Modbus TCP: Würde die Überwachung/Validierung des Wertes nicht wieder eine Störung auf Loxone hervorrufen?

WR nachts aus - Bus kurzgeschlossen oder Spannungsabfall, kann ich mir denken. Würde allenfalls ein weiterer Busteilnehmer nach dem WR (allgemein einem spannungslosem Teilnehmer) etwas bringen?
Hersteller/Typen infolge des gleichen Verhaltens beim Abhängen einzelner Busteilnehmer nicht so relevant... Generelles Problem.

Ist das ähnliche/gleiche Verhalten bei anderen Mastersystemen bekannt?

[hismastersvoice]

Nicht nach Lehrbuch soll heißen, eher Stern- statt Bus- Struktur. Eine provisorische Verlegung der Kabel als Busstruktur hat jedoch keine Besserung gebracht

Ein RS485 Bus ist eigentlich extrem stabil und macht auch mal einen Abzweig mit. Geht in den meisten Fällen (Abschlusswiederstand an jedem Ende wäre noch wichtig)

Bezüglich der extra Modbus Extension oder eben auch Modbus TCP: Würde die Überwachung/Validierung des Wertes nicht wieder eine Störung auf Loxone hervorrufen?

Du musst in dem Fall die Validierung der VIs abschalten und die eine eigene Logik bauen um den Wert zu überwachen.
Ich mache es zB in dem Fall so das zB Sonnenauf- /untergang oder eine Helligkeitsgrenz genutzt wird um die Überwachen zu aktivieren oder zu deaktivieren.

Hersteller/Typen infolge des gleichen Verhaltens beim Abhängen einzelner Busteilnehmer nicht so relevant... Generelles Problem.

Klar ist das relevant, dann könnte man das Handbuch mal anschauen. Solche Sätze liebe ich, wo ist das Problem den Herstelle/Typ zu nennen.
Keine Infos = keine Hilfe.

Ist das ähnliche/gleiche Verhalten bei anderen Mastersystemen bekannt?

Es gibt Busteilnehmer die genauso reagieren wenn man sie abschaltet, das ist aber die Ausnahme und nicht die Regel.
Das ist eher auf ein schlechtes Engineering zurückzuführen
Wie oben geschrieben ist RS485 sehr unempfindlich, da ist RS232 schon deutlich empfindlicher auf Störfaktoren.

[Dani78]

Danke für den Stups.
Busabschlusswiederstände sind eingesetzt. Stabilität des Buses ist mir so eigentlich auch bekannt.

Die Logik wollte ich mir eben sparen... Könnte ich jedoch so umsetzen. Mein Ziel wäre dann eher wieder einen Modbus-Energiezähler einzusetzen, einerseits genauere Produktionswerte und die Logik der Validierung der übrigen Wechselrichterdaten kann einfach umgesetzt werden.

WR nachts aus - Bus kurzgeschlossen oder Spannungsabfall, kann ich mir denken. Würde allenfalls ein weiterer Busteilnehmer nach dem WR (allgemein einem spannungslosem Teilnehmer) etwas bringen? Generelle Frage

Ich will mich nicht bocken, alle Hersteller und Typen der Slaves zu nennen, welche ich vom Bus jeweils einzeln abgehängt habe und diese jeweils die gleiche Störung auf dem Bus (also Störung der Kommunikation mit den anderen Slaves) hervorgerufen haben. Daher meine Aussage - generelles Problem.

Bei anderen Mastersystemen meinte ich den Einsatz des Modbus hinter anderen Mastern, nicht hinter Loxone , nicht das dies mein Ziel wäre, nur reagiert da der Bus oder eben der Master ähnlich? Daher auch die Frage ob es allenfalls von Loxone her kommt...