Verständnisfragen Modbus-Splitter

[Slummi]

Ich habe mal ein paar Verständnisfragen zum Modbus-Splitter.
In der Doku wird darauf nicht wirklich eingegangen und hier im Forum wurde das zwar in einigen Threads angerissen, aber irgendwie nicht so richtig abschließend beantwortet.

1. Unterschied zwischen Modbus TCP und Modbus RTU über TCP
   Was genau ist hier der Unterschied? So richtig erschließt sich mir das nicht.
2. Abfrageverzögerung
   Ist nach meinem Verständnis die Verzögerung zwischen zwei beliebigen Abfragen, die über den Splitter laufen, egal ob Einzelabfragen oder Abfrage von Blöcken. Puffert der Splitter intern alle eingehenden Anfragen aller verbundenen Geräte und arbeitet sie mit dieser Verzögerung ab? Was würde theoretisch passieren, wenn mehr Abfragen eingehen als aufgrund der Verzögerung abgearbeitet werden können?
3. Wartezeit
   Ist nach meinem Verständnis die Zeit, die der Splitter auf eine Antwort zu einer Abfrage wartet, bevor er die Antwort verwirft. Was passiert denn, wenn eine Antwort doch noch eintrifft, aber erst nach Ablauf der Zeit. Wird sie wirklich verworfen oder wird sie doch noch irgendwie an die Geräte weitergeleitet?
4. Verhalten bei gleichen Abfragen, deren Antwort in unterschiedlicher Reihenfolge ankommen.
   Mal angenommen ich stelle alle 5 Sekunden dieselbe Abfrage und meine Wartezeit beträgt 10 Sekunden. Was passiert, wenn die Antwort der ersten Abfrage zwar noch innerhalb der Wartezeit ankommt, die Antwort der zweiten Abfrage aber vor der Antwort der ersten Abfrage eintrifft. Wird die Reihenfolge der Nachrichten erkannt und die Geräte würden die ältere Antwort dann von sich aus verwerfen oder wird dann unter Umständen ein neuerer Wert durch einen älteren überschrieben?
5. Interne Queue
   Hat der Splitter eine interne Queue, in der er alle Abfragen aller angeschlossenen Geräte puffert und der Reihenfolge nach abarbeitet, sodass bei mehreren Geräten mit demselben Abfrageintervall trotzdem sichergestellt ist, dass jedes Gerät bedient wird oder kann es sein, dass ein Gerät öfter zum Zug kommt und das andere leer ausgeht?
6. Mehrere Splitter am selben I/O
   Ich muss teileise über dieselbe TCP-Verbindung unterschiedliche Geräte abfragen. Das geht nur, indem ich mehrere Splitter erstelle, bei denen sich die Geräte-ID unterscheidet. Da die Abfrageverzögerung und Wartezeit auf Splitter-Ebene konfiguriert wird und die interne Queue - sofern vorhanden - auch auf Splitter-Ebene arbeiten wird, kann es sicherlich zu Problemen kommen, weil die Verzögerung zwischen den Abfragen splitter-übergreifend nicht eingehalten werden kann. Gibt es dafür irgendeinen Lösungsansatz? Macht es Sinn, die Verzögerungen zwischen den Splittern unterschiedlich zu wählen, in der Hoffnung, dass im Mittel eine passende Verzögerung über alle gesehen heraus kommt?
7. Welchen Nutzen hat die Blockabfrage auf Splitter-Ebene noch?
   Seit der letzten größeren Überarbeitung ist die Blockabfrage ja in die Geräte-Instanzen gewandert. Im Splitter gibt es sie aber auch noch. Welchen Nutzen hat sie dort noch? Mein Eindruck ist, dass Abfragen, die von einem anderen Gerät kommen oder direkt im Splitter konfiguriert sind, nicht (mehr) an andere Instanzen weitergeleitet werden, wenn diese die gleichen Register abfragen. Kann das sein?

Ich bin immer noch dabei, diverse Modbus-Probleme (z.B. Timeouts) zu analysieren, die mal mehr, mal weniger stark ausgeprägt sind und versuche die möglichen Ursachen einzugrenzen.

[Nall-chan]

Tatsächlich habe ich mich lange nicht mehr mit den letzten Änderungen in Symcon dahingehend beschäftigt, so dass mich 2 bis 7 auch interessieren würden.
Eventuell kann @paresy da mal etwas ins Detail gehen?

Punkt 1 ist dafür einfach.
ModBus TCP und RTU sind zwei verschiedene Protokolle.
Während RTU ursprünglich für reine serielle Anbindungen gedacht war, wird es inzwischen auch bei einigen Geräten (meistens ETH/Seriell Wandler) eingesetzt.

Aus diesem Grund gibt es bei Symcon auch den Modus ModBus RTU über TCP, wo Symcon den Splitter anstatt den seriellen Port einen Client Socket zuordnet.

Allerdings ist RTU über TCP eher eine Krücke und alle Punkte von 2-7 sind hier kritisch zu betrachten, da RTU keine Transaktionsnummer kennt und rein auf Timings setzt.
Sprich auf eine Abfrage muss die dazugehörige Antwort kommen.
Bei ModBus TCP gibt es eine Transaktionsnummer, wodurch sich Abfrage und Antwort zuordnen lassen und auch parallel Abfragen eigentlich kein Problem sein sollten.
Michael

PS: was das jetzt mit MQTT zu tun hat, verstehe ich nicht

[Slummi]

@Nall-chan

PS: was das jetzt mit MQTT zu tun hat, verstehe ich nicht

Ich auch nicht. Kurzzeitiger Synapsen-Ausfall beim Schreiben. Fängt halt beides mit M an… Hab‘s korrigiert.

Danke für die Erklärung zu 1). Das hatte ich nicht auf dem Schirm, dass es da noch ne Zwischenstufe zwischen RTU und TCP gab.

[paresy]

Hier ein paar Antworten:

2. Die Wartezeit zwischen Anfragen, da einige ModBus Geräte (z.B. HUAWEI sehr zickig auf zu viele Anfragen/Sekunde reagieren) Wenn du mehr pro Sekunde anfragst als möglich ist, stapeln sich die Anfragen und da in Symcon Timer nie doppelt laufen können, wird es einfach nur Verzögerungen geben.

3. Wird verworfen, da das Gerät nicht mehr auf die Antwort wartet.

4. Wir warten immer die Wartezeit. Es werden nie gleichzeitig mehrere Anfragen gesendet. Wenn dein Gerät langsamer als 100ms Antwortet würde prüfen, woran das liegt. Gerne Datenblöcke abfragen, wenn möglich.

5. Timer werden immer nacheinander abgearbeitet. Und nur wenn er fertig ist, darf er sich wieder einreihen. Somit wird fair abgearbeitet, aber bei mehr Anfragen als möglich ist, hast du Verzögerungen.

6. Nein. Alle ModBus Splitter sind pro angeschlossenem I/O intern synchronisiert. Egal wie viele Splitter am I/O hängen, es geht immer nur eine Anfrage gleichzeitig raus. Das ist für RTU wie auch TCP gleichermaßen integriert.

7. Keine. Nur noch für die Abwärtskompatibilität. Nicht mehr nutzen

paresy

[Slummi]

Danke für die Antworten.
Ich kann mir zwar noch nicht so ganz vorstellen, wie das mit der Synchronisation über mehrere Splitter (ggf. auch mit unterschiedlichen Verzögerungen) funktioniert. Läuft da im Hintergrund für jeden Abfrage ein eigener Timer? Das wären dann ja unter Umständen ein Haufen Timer, wenn viele Geräte abgefragt werden.

Was muss ich mir denn unter diesen Fehlermeldungen vorstellen? Die sehe ich leider öfter.

Kann Daten nicht zur Instanz weiterleiten: Waiting for buffer usage timed out
Sind da zu viele Abfragen gleichzeitig im Puffer?

Kann Daten nicht zur Instanz weiterleiten: TransactionID stimmt nicht überein
Wie kann die TransactionID nicht übereinstimmen? Die Transaktionen gehen doch von IPS aus.

[paresy]

@Slummi

Kann Daten nicht zur Instanz weiterleiten: Waiting for buffer usage timed out
Sind da zu viele Abfragen gleichzeitig im Puffer?

@Slummi

Kann Daten nicht zur Instanz weiterleiten: TransactionID stimmt nicht überein
Wie kann die TransactionID nicht übereinstimmen? Die Transaktionen gehen doch von IPS aus.

Kommen die Meldungen „nah“ beieinander?

Wenn die Meldung zu spät kommt, kann es sein, dass wir die nächste Transaktion gesendet haben und dann die „alte“ erst kommt. Das kann zu dieser Fehlermeldung führen. Ich muss noch mal prüfen, ob die Aussage „Wir verwerfen veraltete Transaktionen“ korrekt ist.

paresy

[Slummi]

Das ist ganz unterschiedlich. Ja, sie kommen öfter zusammen, teilweise aber auch unabhängig voneinander.

Wenn ich die Abfrageverzögerung und die Wartezeit leicht erhöhe, scheint die Anzahl der Fehlermeldungen auf jeden Fall runter zu gehen.

[Slummi]

Was sind denn WAITING und WAIT_ERROR Nachrichten im Splitter?

Ist dann gar keine Kommunikation möglich? Timeouts dürften es eigentlich nicht sein. Die stehen ja im Klartext in den Debug-Nachrichten und im Log.