Neues Modul für Geräte mit Modbus Schnittstelle über RS232 bzw. RS485

[Herjemine]

Hallo Stefan,

vielen Dank, das schaut gut aus!
Saubere Grafen ohne Ausreißer seit Gestern Abend.

Gruß Hermann

[StefanStrobel]

Hallo,

ich habe das Handling von Modbus TCP nochmal optimiert.
Falls nach einem Timeout doch noch ein Antwort-Frame gelesen wird, wurde bisher auch das folgende Frame gedroppt. Jetzt sollte das Modul versuchen, auch in solchen Fällen das Folgeframe noch zu interpretieren.
Wenn es bei Euch funktioniert, checke ich die Änderung in ein paar Tagen ein.

Zudem wird jetzt bei Get ein :noArg in der Antwort auf ? gesetzt, so dass fhemweb kein Eingabefeld anzeigt.

Gruss
    Stefan

[Herjemine]

Hallo Stefan,

schaut soweit ganz gut aus denke ich.

Edit:
Die "Send queue too long" Meldungen hab ich denk ich größten Teils weg, war ne fhem überlastung 

Hab gerade mal das log ne zeit Tailen lassen,
dabei ist mir aufgefallen, dass ich immer wieder "Send queue too long, dropping request" bekomme,
hast Du einen vorschlag wo ich noch drehen könnte?

Code Auswählen Erweitern


2016.04.13 14:11:42 4: BMV: ParseFrames: fcode 3 from 238, tid 82, data 020c1c e
xpect 3 from 238, tid 82 for module BMV
2016.04.13 14:11:42 4: BMV: ParseObj for Last_discharge assigns 310
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:42 3: CCGX: Send queue too long, dropping request
2016.04.13 14:11:43 4: BMVview: ParseFrames: fcode 3 from 238, tid 168, data 020
148 expect 3 from 238, tid 168 for module BMVview
2016.04.13 14:11:43 4: BMVview: ParseObj for I_A_ assigns 32.8


dev-timing-timeout hab ich schon mal wieder auf 1 zurück gesetzt

Gruß Hermann

[StefanStrobel]

Hallo,

wenn die Send Queue aufgrund zu vieler definierter Einzel-Requests doch mal zu kurz wäre, kann man sie im Modbus-Device auch per queueMax-Attribut verlängert.

Gruss
     Stefan

[Herjemine]

Hallo Stefan,

hast Du für Modbus TCP auch die Möglichkeit vorgesehen ganze Blöcke einzulesen?
da geht ja in einer Abfrage
z.b. den Block  3-41 abzurufen
und dann die Werte einzelnen Readings wie bei der Einzellabfrage zu zuweisen?
Würde denk ich die Systemlast verringern.

oder geht das schon, wenn ich eine zusammenhängende parseInfo structure definiere?

Gruß Hermann

[vknie]

Hallo zusammen,

erstmal einen Dank an Stefan für dieses tolle Tool!

ich habe in fhem auf Raspi 2 mit Erfolg meine diversen AVR-Module mit MODBUS RTU über RS485 und Modbus RTU über TCP in Betrieb genommen.
Da ich mit der Beschreibung des Timings zu einzelnen Requests einige Verständnisprobleme hatte, habe ich viel rumexperimentiert,
um einigermaßen dahinterzukommen.

Dabei ist mir folgende Unregelmäßigkeit aufgefallen:
1.nach einem Neustart laufen alle Modbus-Requests im eingestellten Intervall ab, auch bei Baudraten von bis zu 500000kBit/s!
2.Wird die Intervallzeit über den DEF-Link in der Weboberfläche geändert, bzw. nur der Link angeklickt, damit sich das Fenster zum Ändern öffnet, und das Fenster über den modify-Button geschlossen, werden ab diesem Zeitpunkt alle Requests doppelt in kürzester Zeit ausgeführt, auch wen nichts geändert wurde.
3.Dies trifft sowohl beim seriellen Device zu als auch bei RTU über TCP.
4.Auch bei sehr langen Intervallen von 2 sec habe ich 2 Requests innerhab weniger ms hintereinander.
5.Dies ändert sich nicht mehr. Angesammelte Requests aus einer Queue scheinen es also nicht zu sein.

Hat jemand hierfür eine Erklärung.

Gruß Volker

PS. Habe gerade eben nochmal getestet mit der Version 98-Modbus.pm aus Antwort 211 - kein Unterschied

[StefanStrobel]

Hallo Hermann,

das Basismodul versucht bereits heute die Abfragen zusammenzufassen. Sowohl bei Modbus TCP als auch bei RTU.
Gesteuert wird das per dev-([cdih]-)*combine bzw. über die entsprechende Hash-Struktur bei Modulen auf Basis von Modbus.pm.
Wie hoch man combine setzen kann, hängt vom Device ab. Manche erlauben beim Function code 3 beispielsweise maximal 5 Register in einem Request, andere sogar 50 oder 100.
Wenn combine nicht angegeben wird, geht das Modul von 1 aus und dann gibt es einzelne Requests für jeden Wert.
Bei verbose 5 sieht man das gut im Log.

Gruss
   Stefan

[StefanStrobel]

Hallo Volker,

danke für den Hinweis. Das klingt nach einem Bug.
Ich schau mir das mal an. Vermutlich fehlt ein RemoveInternalTimer in der Define Funktion ...

Gruss
    Stefan

[vknie]

Hallo Stefan,
was mir noch aufgefallen ist - wenn Modbus RTU seriell und über TCP benutzt wird, werden beim Start doppelte Funktionsdefinitionen aus dem MODBUS-pm-Modul im Logfile eingetragen, wenn die TCP-Variante vor der seriellen definiert wird. Ich weiß nicht, ob das nur unschön ist oder noch Folgen hat.
Definiert man das serielle Device als erstes, bleiben die Fehlermeldungen/Warnungen aus.

Gruß

Volker   

[StefanStrobel]

Hallo Volker,

das ist unschön, sollte aber keine negativen Folgen haben.
Anbei eine korrigierte Version von Modbus und ModbusAttr. Wenn die keine Probleme machen, checke ich sie ein.

Gruss / Thanx
    Stefan

EDIT 14.7.16: angehängte alte Module entfernt

[vknie]

Hallo Stefan,

ich habe beide Varianten mit deinen neuen Dateien ausprobiert und konnte den Fehler mit den doppelten Requests nicht mehr feststellen, weder bei der RTU über TCP-Variante als auch bei der RS232/RS485-Variante.
Ich denke, dass der Fehler damit behoben ist.

Gruß und Danke

Volker

[Burny4600]

Läßt sich das irgendwie mit einem RS485 Modbus auf TCP/IP auch realisieren.

Ich möchte einen SDM630M/Modbus an einem RS485/Modbus-TCP/IP Konverter betreiben.
Mir fehlt aber noch der Durchblick wie ich das konfigurationstechnisch umsetzten kann.

Vielleicht hat hier ja schon jemand eine Lösung.

[StefanStrobel]

Hallo Chris,

das sollte eigentlich funktionieren.
Wenn Dein Konverter Modbus-TCP (port 502) spricht, kannst Du seine IP-Adresse und TCP als Modus beim Define angeben.
Wenn er Modbus-RTU über einen TCP-Port spricht, kannst Du seine Adresse und Modus RTU angeben.

Gruss
   Stefan

[Herjemine]

Hallo Stefan,

das combine geht super, alle Werte mit einer Abfrage ..

so jetzt noch ne dumme Frage 

wie kann ich Ihn eigentlich einfach zu nem TCP reconnect überreden?
Bisher mach ich immer ein defmod mit geänderem Port.

Gruß Hermann

[StefanStrobel]

Hallo Hermann,

gute Frage.
Ich habe leider kein Modbus-TCP Gerät zum Testen und habe mich bisher darauf verlassen, dass der Status disconnected in der _Ready Funktion zu einem neuen OpenDev führt.
Wenn das nicht funktioniert muss ich mir das nochmal intensiver ansehen.

Gruss
    Stefan