Neue Versionen und Support zum Modbus-Modul

Begonnen von StefanStrobel, 20 August 2017, 12:11:08

Vorheriges Thema - Nächstes Thema

mba

Hallo Stefan,

ich wollte das testen, allerdings verschwinden dann meine bisherigen modbusattr definitionen.

2018.09.30 14:52:29.979 1: define mbSlave10 ModbusAttr 10 0.1: Usage: define <name> ModbusAttr <id> <interval>|slave|relay|passive [host:port] [RTU|ASCII|TCP] [to <relayMasterDevice>]
2018.09.30 14:52:30.478 1: Including /opt/fhem/fhem.save
2018.09.30 14:52:35.604 1: configfile: Usage: define <name> ModbusAttr <id> <interval>|slave|relay|passive [host:port] [RTU|ASCII|TCP] [to <relayMasterDevice>]
/opt/fhem/fhem.save: Please define mbSlave10 first
Please define mbSlave10 first
Please define mbSlave10 first
...
2018.09.30 14:52:35.877 3: Opening RS485 device /dev/ttyS2
2018.09.30 14:52:35.902 3: Setting RS485 serial parameters to 115200,8,N,2
2018.09.30 14:52:35.903 3: RS485 device opened
2018.09.30 14:52:35.903 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/98_Modbus.pm line 1460.


Müssen die angepasst werden?

Grüße
Marco
Tinkerboard für FHEM, Modbus RTU via RS485 mit Arduino Slaves, ZWAVE mit Razberry Modul

Andi291

Moin!

Ich hatte mir einen eigenen logger geschrieben, den ich nun nicht mehr brauche.
Ich habe zwar noch Probleme beim Umschlüsseln der Register, das liegt aber (denke ich) nicht im Modul.

Zusammenfassend: Positives Feedback, bitte einchecken!

Grüße, Andi

StefanStrobel

Hallo Marco,

danke für's Testen.
Offensichtlich verwendest Du 0.1 als Intervall.
Bei all den Änderungen habe ich offenbar übersehen, dass man bisher auch Bruchteile von Sekunden verwenden konnte.
Der aktuelle Stand akzeptiert nur ganzzahlige Intervalle. Das ändere ich wieder und poste dann heute am Abend oder Morgen eine aktualisierte Version.

Gruss / vielen Dank
    Stefan

StefanStrobel

Hallo Andi,

Auch an Dich vielen Dank fürs Testen!
Ich werde noch ein paar Tage warten, bis mehr Feedback eingetroffen ist, um solche Probleme wie sie von Marco gefunden wurden noch zu beheben.
Dann checke ich es ein :-)

Gruss / Thanx
    Stefan

StefanStrobel

Hallo,

anbei eine neue Version, in der die Intervalle beim define wieder so funktionieren sollten wie bisher :-)

Gruss
   Stefan

mba

#125
Hallo Stefan,

ich habe die neue Version eingespielt, es kommen aber ständig timeouts.
Die Readings der Slaves werden aktualisiert, also funktionieren tut es wohl.
Ich habe die Pollintervalle und timeouts  auf möglichst kleine werte gesetzt.
Dadurch sind die Slaves fast in Echtzeit abzufragen.
Hat mit dem alten Modul auch gut funktioniert bei knapp 100000 request pro stunde und vielleicht 1 bis 3 timeouts pro Tag.

Gruß
Marco


2018.10.01 21:41:53.517 3: Opening RS485 device /dev/ttyS3
2018.10.01 21:41:53.518 3: Setting RS485 serial parameters to 115200,8,N,2
2018.10.01 21:41:53.518 3: RS485 device opened
2018.10.01 21:41:53.519 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/98_Modbus.pm line 1461.
2018.10.01 21:41:53.522 3: mbSlave11: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.522 3: mbSlave11: RegisterAtIODev to RS485 with id 11, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.522 3: mbSlave12: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.522 3: mbSlave12: RegisterAtIODev to RS485 with id 12, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.522 3: mbSlave13: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.522 3: mbSlave13: RegisterAtIODev to RS485 with id 13, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.523 3: mbSlave14: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.523 3: mbSlave14: RegisterAtIODev to RS485 with id 14, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.523 3: mbSlave21: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.523 3: mbSlave21: RegisterAtIODev to RS485 with id 21, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.524 3: mbSlave22: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.524 3: mbSlave22: RegisterAtIODev to RS485 with id 22, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.524 3: mbSlave23: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.524 3: mbSlave23: RegisterAtIODev to RS485 with id 23, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.524 3: mbSlave24: Notify / Init: using RS485 for communication
2018.10.01 21:41:53.525 3: mbSlave24: RegisterAtIODev to RS485 with id 24, MODE master, PROTOCOL RTU
2018.10.01 21:41:53.555 0: Featurelevel: 5.8
2018.10.01 21:41:53.556 0: Server started with 75 defined entities (fhem.pl:17329/2018-09-12 perl:5.022001 os:linux user:fhem pid:5878)
2018.10.01 21:41:56.342 3: RS485: Timeout waiting for a modbus response, request: id 14, fCode 3, type h, adr 142, len 7 for device mbSlave14 reading ro-DHT1dewPoint, read buffer empty
2018.10.01 21:41:57.201 3: RS485: Timeout waiting for a modbus response, request: id 11, fCode 3, type h, adr 134, len 8 for device mbSlave11 reading ro-SensorMotion1, read buffer empty
2018.10.01 21:41:58.052 3: RS485: Timeout waiting for a modbus response, request: id 12, fCode 3, type h, adr 135, len 9 for device mbSlave12 reading ro-SensorMotion1, read buffer empty
2018.10.01 21:41:59.138 3: RS485: Timeout waiting for a modbus response, request: id 11, fCode 3, type h, adr 134, len 8 for device mbSlave11 reading ro-SensorMotion1, read buffer empty
2018.10.01 21:41:59.994 3: RS485: Timeout waiting for a modbus response, request: id 12, fCode 3, type h, adr 126, len 7 for device mbSlave12 reading ro-SlaveMaxLooptime, read buffer empty
2018.10.01 21:42:00.867 3: RS485: Timeout waiting for a modbus response, request: id 12, fCode 3, type h, adr 126, len 9 for device mbSlave12 reading ro-SlaveMaxLooptime, read buffer empty
2018.10.01 21:42:02.012 3: RS485: Timeout waiting for a modbus response, request: id 1, fCode 3, type h, adr 125, len 9 for device mbSlave01 reading ro-DoorOpener, read buffer empty
2018.10.01 21:42:02.854 3: RS485: Timeout waiting for a modbus response, request: id 22, fCode 3, type h, adr 137, len 11 for device mbSlave22 reading ro-SensorLight1, read buffer empty
2018.10.01 21:42:03.683 3: RS485: Timeout waiting for a modbus response, request: id 11, fCode 3, type h, adr 126, len 8 for device mbSlave11 reading ro-SlaveMaxLooptime, read buffer empty
2018.10.01 21:42:04.514 3: RS485: Timeout waiting for a modbus response, request: id 12, fCode 3, type h, adr 135, len 9 for device mbSlave12 reading ro-SensorMotion1, read buffer empty
2018.10.01 21:42:05.358 3: RS485: Timeout waiting for a modbus response, request: id 14, fCode 3, type h, adr 126, len 8 for device mbSlave14 reading ro-SlaveMaxLooptime, read buffer empty


mit verbose 5 als Anhang
Tinkerboard für FHEM, Modbus RTU via RS485 mit Arduino Slaves, ZWAVE mit Razberry Modul

StefanStrobel

#126
Hallo Marco,

Dein Log mit verbose 5 beginnt leider erst als der Timeout schon unterwegs ist. Es wäre spannend zu sehen, was davor passiert ist.
Anbei nochmal eine neue Version, die etwas eleganter mit dem Queue-Timer umgehen sollte und weniger überflüssige Dinge protokolliert.
Ich vermute, dass es ein Timing-Problem ist. Deine Anwendung mit Intervall 0.1 und QueueDelay 0 ist schon extrem ;-)
Eventuell ist die neue Version an ein paar Stellen effektiver als die alte und dadurch könnte ein Slave zu schnell abgefragt werden.
Probier doch mal die Delays minimal zu erhöhen, ob das einen Unterschied macht. Falls nicht, könnten wir die Logs der alten mit den Logs der neuen Version vergleichen.

Gruss / vielen Dank
   Stefan

mba

Hallo Stefan,

ich habe diesmal verbose 5 eingestellt bevor ich fhem neugestartet habe.
Also findest du Einträge mit der alten und der neuen Version.
ich versuche mal die timings hochzuschrauben bis die Fehler weg sind.
Vielleicht gibt das mehr Aufschluss.

Tinkerboard für FHEM, Modbus RTU via RS485 mit Arduino Slaves, ZWAVE mit Razberry Modul

mba

ich habe am RS485 Port jetzt mal busDelay (vorher nicht vorhanden) und ClientSwitchDelay (vorher 0.3s) auf 1s
und auf den Slaves dev-timing-sendDelay (vorher 0.015) und dev-timing-commDelay (vorher 0) auf 1s gestellt.
Timeouts bleiben.
Tinkerboard für FHEM, Modbus RTU via RS485 mit Arduino Slaves, ZWAVE mit Razberry Modul

StefanStrobel

Hallo,

ich glaube da ist ein Bug im delay-Handling. Teilweise gehen die Request 12ms oder sogar nur 5ms nach dem letzten Lesen raus.
Die Delays werden wohl nicht richtig umgesetzt. Das erklärt dann auch die Timeouts.
Ich melde bald mich mit einer neuen Version.

Gruss und vielen Dank
   Stefan

StefanStrobel

Hier eine neue Version, bei der die Delays wieder funktionieren sollten.

Gruss
   Stefan

mba

#131
Hallo Stefan,

das sieht gut aus, die Timeouts sind weg und es scheint alles zu funktionieren.

Ich habe mich in der Zwischenzeit nochmal näher mit dem Timing auseinandergesetzt.

bei 115200 Baud mit 8N2 = startbit+databits+parity/stopbit+stopbit = 1+8+1+1 = 11 bits per character
1s / 115200 Baud = 8,6805 µs per bit, 11 bit per character = 95,5 µs per character
Modbus Spezifikation Busdelay = min. 3.5 * character time = 335 µs

eine Requestfolge:
Busdelay = 335 µs
Master Request Frame = 8 byte = 8 * char time = 764 µs
Busdelay = 335 µs
Slave Response 25regs = ModbusFrame + HoldingRegs(16bit) = 5+25*2 = 55 characters = 5252,5 µs
Slave Response 11regs = ModbusFrame + HoldingRegs(16bit) = 5+11*2 = 27 characters = 2578,5 µs
Slave Response 10regs = ModbusFrame + HoldingRegs(16bit) = 5+10*2 = 25 characters = 2387,5 µs
Slave Response 9 regs = ModbusFrame + HoldingRegs(16bit) = 5+9 *2 = 23 characters = 2196,5 µs
Slave Response 8 regs = ModbusFrame + HoldingRegs(16bit) = 5+8 *2 = 21 characters = 2005,5 µs
Slave Response 4 regs = ModbusFrame + HoldingRegs(16bit) = 5+4 *2 = 13 characters = 1241,5 µs
Slave Response 1 regs = ModbusFrame + HoldingRegs(16bit) = 5+1 *2 = 7  characters =  668,7 µs

Theoretische Zykluszeit bei 25 Regs = Request + Response = 6,7 ms
Theoretische Zykluszeit bei 11 Regs = Request + Response = 4,0 ms
Theoretische Zykluszeit bei 10 Regs = Request + Response = 3,8 ms
Theoretische Zykluszeit bei  9 Regs = Request + Response = 3,6 ms
Theoretische Zykluszeit bei  8 Regs = Request + Response = 3,4 ms
Theoretische Zykluszeit bei  4 Regs = Request + Response = 2,7 ms
Theoretische Zykluszeit bei  1 Regs = Request + Response = 2,1 ms

Da ich bei meinen Slaves zwischen 8 und 11 Regs pro Request hole, rechne ich mal mit 5 ms.
Daraus schließe ich das folgende Einstellungen laufen sollten.

RS485:
busDelay = 0.001
clientSwitchDelay = 0.01 (nutze ich um den Slaves 10ms Zeit für ihren eigenen Loop zu geben)
queueDelay = 0

Slaves:
dev-h-combine = 8 bis 11
dev-timing-commDelay = 0
dev-timing-sendDelay = 0.005

Bei 9 Slaves mit 1 x 3 Requests und 8 x 2 Requests
= 19 Requests a 5ms + 19 sendDelay a 5ms + 9 x clientSwitchdelay a 10ms + 19 x Busdelay a 1ms
= 299ms Looptime

also mit Reserven geht ein Pollintervall von 0.4s, habe ich jetzt auch so laufen.
Ich hoffe die Timings so richtig interpretiert zu haben, zumindest läuft es so.

Wenn ich noch wünsche äußern dürfte,
- fände ich die Möglichkeit gut wie eine Statemachine kontinuierlich abzuholen anstatt in Intervallen zu pollen.
- ein reading mit dem Füllgrad der Queue
- ein evtl. sogar konfigurierbares retry bei einem Timeout, da es doch manchmal welche gibt, speziell wenn man so hart an der physikalischen grenze fährt wie ich es tue

Ansonsten kann ich mich nur für das Modul bedanken

Grüße
Marco



Tinkerboard für FHEM, Modbus RTU via RS485 mit Arduino Slaves, ZWAVE mit Razberry Modul

StefanStrobel

Hallo Marco,

das mit dem Reading für die Länge der Queue ist kein Problem. Ebenso eine Möglichkeit für Retries nach Timeouts.
Nur das mit der Statemachine müsstest Du etwas genauer erklären.

Gruss und Danke für's Testen
    Stefan

mba

Anstatt eine fixe Zeit anzugeben wann gepollt wird, irgend ein anderes Flag.
Wenn gesetzt wird dann kontinuierlich gepollt, sobald alle Slaves mit den passenden Registern durch sind fängt es direkt von vorne wieder an. Evtl. gesetzte polldelay Attribute könnten dann als Faktor eines kompletten Durchlaufs interpretiert werden.
Dann wäre allerdings ein reading schön aus dem die Zeit für einen kompletten Durchlauf ersichtlich ist damit man weis was als polldelay in Frage kommt.
Ein set Befehl könnte direkt zwischen den einzelnen Requests oder nach Beendigung eines kompletten Durchlaufs erfolgen, abhängig vom nonPrioritizedSet Attribut.

Das nur als Gedankenspiel
Tinkerboard für FHEM, Modbus RTU via RS485 mit Arduino Slaves, ZWAVE mit Razberry Modul

mba

Hallo Stefan,

hab noch ein Problem gefunden, auf meinem Windows Rechner stürzt der FHEM Prozess ab sobald ich die neue Modbusversion nutze.
Nur wenn das RS485 Device auf disable steht kann ich FHEM starten, mit der alten Version läuft es.

alte version

2018.10.10 23:35:11 1: starting in console mode
2018.10.10 23:35:11 1: Including fhem.cfg
2018.10.10 23:35:11 3: telnetPort: port 7072 opened
2018.10.10 23:35:12 3: WEB: port 8083 opened
2018.10.10 23:35:12 3: WEBphone: port 8084 opened
2018.10.10 23:35:12 3: WEBtablet: port 8085 opened
2018.10.10 23:35:12 2: eventTypes: loaded 184 events from ./log/eventTypes.txt
2018.10.10 23:35:12 3: mbSlave10: defined with id 10, interval 0.1, protocol RTU
2018.10.10 23:35:12 1: PERL WARNING: Use of uninitialized value $L[7] in hex at (eval 23) line 1, <$fh> line 126.
2018.10.10 23:35:12 1: PERL WARNING: Use of uninitialized value $L[0] in concatenation (.) or string at (eval 23) line 1, <$fh> line 126.
2018.10.10 23:35:12 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 23) line 1, <$fh> line 126.
2018.10.10 23:35:12 3: mbTest: defined with id 5, interval 1, protocol RTU
2018.10.10 23:35:12 3: mbTest: Support for leading zeros in object addresses enabled. This might slow down the fhem modbus module a bit
2018.10.10 23:35:12 1: Including ./log/fhem.save
2018.10.10 23:35:12 3: RS485: Notify / Init: opening connection
2018.10.10 23:35:12 3: Opening RS485 device COM3
2018.10.10 23:35:12 3: Setting RS485 serial parameters to 115200,8,N,2
2018.10.10 23:35:12 3: RS485 device opened
2018.10.10 23:35:12 3: mbSlave10: Notify / Init: device is disabled
2018.10.10 23:35:12 3: mbTest: Notify / Init: using RS485 for communication
2018.10.10 23:35:12 0: Featurelevel: 5.9
2018.10.10 23:35:12 0: Server started with 12 defined entities (fhem.pl:17488/2018-10-08 perl:5.024002 os:MSWin32 user:qwertz pid:13088)


neue Version

2018.10.10 23:38:46 1: starting in console mode
2018.10.10 23:38:46 1: Including fhem.cfg
2018.10.10 23:38:46 3: telnetPort: port 7072 opened
2018.10.10 23:38:46 3: WEB: port 8083 opened
2018.10.10 23:38:46 3: WEBphone: port 8084 opened
2018.10.10 23:38:46 3: WEBtablet: port 8085 opened
2018.10.10 23:38:46 2: eventTypes: loaded 184 events from ./log/eventTypes.txt
2018.10.10 23:38:46 3: RS485: defined as COM3@115200,8,N,2
2018.10.10 23:38:46 3: mbSlave10: defined with id 10, interval 0.1, protocol default (RTU), mode master
2018.10.10 23:38:46 3: mbSlave10: UnregAtIODev called from ModbusLD_SetIODev
2018.10.10 23:38:46 3: mbSlave10: RegisterAtIODev called from ModbusLD_SetIODev registers mbSlave10 at RS485 with id 10, MODE master, PROTOCOL RTU
2018.10.10 23:38:46 1: PERL WARNING: Use of uninitialized value $L[7] in hex at (eval 23) line 1, <$fh> line 126.
2018.10.10 23:38:46 1: PERL WARNING: Use of uninitialized value $L[0] in concatenation (.) or string at (eval 23) line 1, <$fh> line 126.
2018.10.10 23:38:46 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at (eval 23) line 1, <$fh> line 126.
2018.10.10 23:38:47 3: mbTest: defined with id 5, interval 10, protocol default (RTU), mode master
2018.10.10 23:38:47 3: mbTest: UnregAtIODev called from ModbusLD_SetIODev
2018.10.10 23:38:47 3: mbTest: RegisterAtIODev called from ModbusLD_SetIODev registers mbTest at RS485 with id 5, MODE master, PROTOCOL RTU
2018.10.10 23:38:47 3: mbTest: attr support for leading zeros in object addresses enabled. This might slow down the fhem modbus module a bit
2018.10.10 23:38:47 1: Including ./log/fhem.save
2018.10.10 23:38:47 4: RS485: Notify / Init: opening connection
2018.10.10 23:38:47 5: RS485: Open called for DevIo connection - closing first
2018.10.10 23:38:47 5: RS485: Close called from Open with noState
2018.10.10 23:38:47 4: RS485: open trying to open connection to COM3@115200,8,N,2
2018.10.10 23:38:47 3: Opening RS485 device COM3
2018.10.10 23:38:47 3: Setting RS485 serial parameters to 115200,8,N,2
2018.10.10 23:38:47 3: RS485 device opened
2018.10.10 23:38:47 3: mbSlave10: Notify / Init: device is disabled
2018.10.10 23:38:47 3: mbTest: UnregAtIODev called from Notify
2018.10.10 23:38:47 3: mbTest: Notify / Init: using RS485 for communication
2018.10.10 23:38:47 3: mbTest: RegisterAtIODev called from Notify registers mbTest at RS485 with id 5, MODE master, PROTOCOL RTU
2018.10.10 23:38:47 0: Featurelevel: 5.9
2018.10.10 23:38:47 0: Server started with 12 defined entities (fhem.pl:17488/2018-10-08 perl:5.024002 os:MSWin32 user:qwertz pid:5896)
2018.10.10 23:38:48 5: RS485: Profiling Fhem initialized, start 1539207528.21466
2018.10.10 23:38:48 5: RS485: QueueRequest called from ModbusLD_DoRequest with h003, qlen 0
2018.10.10 23:38:48 5: RS485: ProcessRequestQueue called from QueueRequest as direct:RS485
2018.10.10 23:38:48 5: RS485: Open called for DevIo connection - closing first
2018.10.10 23:38:48 5: RS485: Close called from Open with noState
2018.10.10 23:38:48 4: RS485: open trying to open connection to COM3@115200,8,N,2
2018.10.10 23:38:48 3: Opening RS485 device COM3
Zugriff verweigert

2018.10.10 23:38:48 1: PERL WARNING: can't open device: \\.\COM3
at ./FHEM/DevIo.pm line 414.
2018.10.10 23:38:48 1: RS485: Can't open COM3:
2018.10.10 23:38:48 5: RS485: Profiling Idle, before Fhem, now is 1539207528.22875, Idle started at 1539207528.22875, Fhem started at 1539207528.21466
2018.10.10 23:38:48 5: RS485: Profiling add 0.0140969753265381 to sum for Fhem (now is 1539207528.22875, start for Fhem was 1539207528.21466)
Can't use an undefined value as an ARRAY reference at ./FHEM/98_Modbus.pm line 3077.
Tinkerboard für FHEM, Modbus RTU via RS485 mit Arduino Slaves, ZWAVE mit Razberry Modul