MODBUS - Auslesen von Register Reihenfolge - wie?

[schurli]

Hallo,

ich muss auf Grund technischer Gegebenheiten von einem TCP Modbus-fähigen Gerät mit einer einzigen Abfrage eine "Reihenfolge" von 16 Bit Registern auslesen anstatt einzelner Register. Im meinem konkreten Fall heißt das, ich möchte 4 aufeinander folgende Blöcke á 20 16-Bit Register (=160 Bytes) mit einem Auslesevorgang auslesen. Loxone bietet dazu die Möglichkeit, siehe unten.

Meine Frage(n): In welcher Form übergibt mir Loxone diese Registerreihenfolge? Als Text-String?

Danach möchte ich einzelne Register aus dieser Registerreihenfolge herauslesen. Wie mache ich das? z.B. ich möchte danach den Wert des 5. und des 25. 16-Bit Registers wissen. Wie geht das?

Hat jemand eine Idee?

Danke

[Bogenhaus]

Hallo, wäre praktisch wenn dies den wirklich ginge was du dir vorstellst.
Du kannst jedoch nur einen Wert lesen , als 16, 32 oder 64 Bit Wert. Das was du markiert hast dient dann dazu HighWord/LowWord zu swappen
Das ergbnis ist dann ein entsprechender Analogwert

[schurli]

Hallo, wäre praktisch wenn dies den wirklich ginge was du dir vorstellst.
Du kannst jedoch nur einen Wert lesen , als 16, 32 oder 64 Bit Wert. Das was du markiert hast dient dann dazu HighWord/LowWord zu swappen
Das ergbnis ist dann ein entsprechender Analogwert

echt? Das wäre schade. Weil der "normale" Modbus Standard gibt das schon her, da gibt es genau eine solche Funktion. Bis zu 256 Bytes (inkl. Overhead) können in einem Schwung ausgelesen werden, so wie ich die Dokumentation im Internet verstehe.

[Jan W.]

echt? Das wäre schade. Weil der "normale" Modbus Standard gibt das schon her, da gibt es genau eine solche Funktion. Bis zu 256 Bytes (inkl. Overhead) können in einem Schwung ausgelesen werden

Loxone kennt keine Arrays, wie viele Programmiersprachen. Daher können nur einzelne Zahlen gelesen und über die "Verdrahtungslogik" verarbeitet werden. Es gibt aber ein Datentyp 64-Bit unsigned Integer mit dem 4 Byte gelesen werden können (siehe Erklärung für Option "16-Bit Register"). Danach muss man über Division und Rest die einzelnen Teile herausrechnen - zuerst mit 65536 und dann mit 256, falls man die 4 einzelnen Bytes benötigt. Eigentlich sollte man Arrays auch einzeln über aufeinanderfolgende Register lesen können.

Wenn Dir das nicht hilft, dann könnte man das über Pico-C nachprogrammieren, aber da ein Programmbaustein maximal 13 Ausgänge hat, wären auch hier Grenzen gesetzt. Eine Verarbeitung der 160 Bytes innerhalb des Pico-C Programmes wäre problemlos möglich.

[schurli]

Danke für die ganzen Rückmeldungen. Hatte gehofft hier eine Lösung für ein Problem mit einem Modbus Gerät zu finden, das keine große Anzahl von Modbus Abfragen verträgt.

[Jan W.]

Wenn Du nur ein paar Register am Ende benötigst und Kenntnisse in C hast, wäre Pico-C schon eine Lösung. Ich musste Modbus/TCP manuell programmieren, weil Helios das Protokoll nicht ganz verstanden hat und man eine Variable zuerst als String schreiben muss, um den (Zahlen-)Wert anschließend als String zu lesen. Der Code für Deine Anforderung wäre ziemlich einfach.

Das Programm https://loxwiki.atlassian.net/wiki/s...t+easycontrols könntest Du als Vorlage nehmen, insbesondere die Funktion "modbusTCPreadVar" und noch mit Anfangsregister und Anzahl der zu lesenden Register entsprechend anpassen.

[schurli]

Wenn Du nur ein paar Register am Ende benötigst und Kenntnisse in C hast, wäre Pico-C schon eine Lösung. Ich musste Modbus/TCP manuell programmieren, weil Helios das Protokoll nicht ganz verstanden hat und man eine Variable zuerst als String schreiben muss, um den (Zahlen-)Wert anschließend als String zu lesen. Der Code für Deine Anforderung wäre ziemlich einfach.

Das Programm https://loxwiki.atlassian.net/wiki/s...t+easycontrols könntest Du als Vorlage nehmen, insbesondere die Funktion "modbusTCPreadVar" und noch mit Anfangsregister und Anzahl der zu lesenden Register entsprechend anpassen.

Danke Jan für den Tipp. Habe leider keine Ahnung von C & Pico und das Programm schaut für den Laien nicht gerade leicht verständlich aus :-)

Interessant ist dein Problem mit der Helios WRL. Ich habe ein KL-Lufttechnik Gerät (österr. Firma), welches zur Steuerung mit Loxone hard-wired (pot-freie Kontakte) ist. D.h. ich kann alle Lüftungsstärken einstellen, aber mehr nicht.

Seit kurzem gibt es für dieses Gerät auch eine TCP-Modbus Schnittstelle. Habe in die Anleitung reingelesen (vielleicht zahlt sich eine Aufrüstung aus?). Nur das Auslesen der Modbusregister scheint dort ähnlich kompliziert zu sein. Hier der O-Text:

Eine Abfrage darf nur aus hintereinanderliegenden Adressen lesen.
Grund: aus nicht definierten Registern darf nicht gelesen werden
Lösung: mehrere Abfragen erstellen, die die Register blockweise abfragen
Beispiel: 1. Abfrage: Register 650,651,652,653,654,655 2. Abfrage: Register 700,701,702

und genau diese blockweise Abfrage und das sequentielle Auslesen würde in Loxone nicht gehen.

[Bogenhaus]

So wie das hier beschrieben ist schliesst es eine Loxone Lösung nicht aus.
Hier geht es darum das man nur spezifizierte Register lesen darf - wie im Beispiel nicht 650 bis 702 durchgehend.
Es scheint aber nichts dagegen zu sprechen die jeweiligen Register 650-655 und 700-702 jeweils einzeln zu lesen

Das einzelne lesen von Registern hat nur das Risiko dass wenn Register zueinander korrelieren (z.B. Wert plus Skalierungsfaktor) es zu Inkonsistenten führen kann.

[Noschvie]

Ad WRL von KL Lufttechnik: habe diese über Modbus RTU und einem Modbus TCP Gateway in Loxone eingebunden. Steuerung und Anzeige funktionieren problemlos.

[schurli]

Ad WRL von KL Lufttechnik: habe diese über Modbus RTU und einem Modbus TCP Gateway in Loxone eingebunden. Steuerung und Anzeige funktionieren problemlos.

ja, bei Modbus RTU scheint es diese Einschränkungen nicht zu geben. Warum brauchst du das TCP Gateway und verwendest nicht direkt die Loxone RTU Modbus Extension?

[Noschvie]

Wollte mich nicht auf die Loxone Modbus Extension verlassen, sondern gleich auf TCP gehen.

Hast du einen Link zur Docu der "Modbus TCP Schnittstelle"?

[Bogenhaus]

die ModBus Extension macht dabei keinen Unterschied - es lassen sich auch hier nur einzelne Werte 16/32 oder 64 Bit laden und keine ganzen Arrays

[schurli]

das ist schon klar. Nur die RTU (alt) und TCP (neu) Modbuseinheiten dürften unterschiedlich sein

[Jan W.]

Ich glaube nicht, dass es einen Unterschied macht, ob ein Gerät mit Modbus/RTU Schnitstelle über die entsprechende Loxone Extension oder ein Umsetzer von Modbus/RTU auf TCP angesprochen wird (außer vielleicht im Geldbeutel). Das minimale Abfrageintervall für Modbus/TCP, welches Loxone als künstliche Restriktion eingebaut hatte, um billige I/O Geräte auszuschließen, gibt es nicht mehr.

Eine Abfrage darf nur aus hintereinanderliegenden Adressen lesen.

Diese Beschränkung wird immer vorhanden sein. In Deinem Bespiel wäre es nicht erlaubt 52 Register von 650 bis 702 in einer Abfrage zu lesen. Die Beschränkung bedeutet aber nicht, dass Du die Register 650 bis 655 in einer Abfrage lesen musst. Ein etwas höherer Overhead ist natürlich vorhanden, wenn einzelne Register nacheinander gelesen werden. Wie Noschvie bestätigt, ist die Einbindung des Gerätes kein Problem - auch wenn Loxone keine Arrays kennt und daher jeden Wert einzeln abfragt.

[schurli]

Jaja, alles schon klar. Ich habe eine Hoymiley DTU meiner PV Anlage und ich möchte von der im ca. 10s Abstand 20 verschieden Register auslesen. Nur das Teil stürzt dann 3-5x täglich ab und muss dann aus- und wieder eingeschalten werden. Warum? Weil lt. Hoymiles Support die DTU Mindestabstände von 1s zwischen einzelnen Abfragen benötigt. Und jeder der schon einmal in den Modbus Monitor von Loxone reingeschaut hat weiß, dass die Abstände zwischen einzelnen Abfragen absolut erratisch sind.

Das Problem wurde von anderen Anwendern eben so gelöst, dass sie anstatt von 20 Einzelabfragen 2 o. 3 Abfragen von ganzen Registereihenfolgen durchführen und sich dann die Einzelwerte aus dem Datenpaket rausholen. Aber das geht halt bei Loxone nicht ....

[Tico]

I offer the following observations regarding Modbus polling. Please excuse the English, but sometimes I don't trust the Translator.

I have logic that measures the update rate of Modbus polling of a Fronius inverter -



Through trial and error, I've established that 400ms is the shortest Timeout value I can set in the Loxone Config before errors are generated. I have 21 sensors being polled at 10 second intervals. 21 x 400ms = 8.4 seconds.

The real update rate averages 11.5 seconds despite the Polling cycle being set at 10 seconds. Loxone appears to attempt to meet the update rate, but with too many sensors, it simply starts the sequence again when the polling sequence of 21 sensors is complete. There appears to be an overhead in polling time between the 'theoretical' best case of 8.4 seconds and the reality of 11.5 seconds.

The only method to improve polling rate towards 10 seconds is to reduce the number of sensors. I have already exhausted optimisation of Timeout.

In the image below, I have adjusted Timeout from 400ms to 1000ms with no other changes (ie. Polling cycle remains at 10 seconds) -



This has halved the polling rate (or doubled the timeframe for a given sensor update). 21 sensors x 1000ms = 21 seconds. This is placing far less demand on the Fronius inverter at the expense of update frequency in Loxone.

Lastly, Timeout is adjusted to 2000ms with no other changes (21 x 2000ms = 42 seconds) -




This is a further commensurate reduction in polling rate with less demand placed on the Fronius inverter. The Timeout 'bulks-out' the ability to get through the full 21 sensors in a timely fashion.

The Miniserver polls sensors in the order they are created. As an experiment, I would delete all your existing sensors and start again from the lowest register. Create the first sensor as '64bit unsigned integer' to read in as much data as possible in one polling sequence. Then create the second sensor +4 IO Addresses higher than the first. Then the 3rd sensor etc...

This also assumes there's no 'padding' between register values and the data is one contiguous field.

You will then have 'blobs' of data that can be mathematically parsed to extract the individual register fields (as Jan W. mentioned in Post #4). Before trying to parse the values, I would check to see whether this method of polling crashes your Hoymiley DTU.

Using 2000ms Timeout x 5 'sensors' would contain about 20 x 8 bit data fields in a 10 second period.

[Noschvie]

Wenn das Problem mehrere Anwender haben, warum schreibt nicht jemand ein Plugin zum Beispiel in Python, um die Register auszulesen, die notwendigen Werte zu berechnen und über MQTT oder UDP weiterzugeben?
Es gibt sicher auch andere Möglichkeiten für eine Lösung.

[Jan W.]

Hi Tico,
it is interesting that the timeout value looks to have an impact on the polling cycle. The timeout value in Loxone for my heat pump is 100 ms and I'm polling about 38 parameters every 60 seconds. I had a look on the Modbus communication between my MS (10.1.1.5) and a heat pump, a Stiebel Eltron ISGweb (a 10 year old linux based control unit that is binary compatible with a Raspberry PI):



I added a column "delta" to display the delta time between this frame an the previous one that is displayed. It looks that this device is able to answer all Modbus requests within about 0,5 ms. Loxone is not that accurate with the polling cycle, but it's more to 60 than to 60,1 seconds. The polling does not affect the cpu of the ISGweb:


The load for the modbus server (isg_mbh) is about 0%.

[Tico]

It could be something that's unique to the Fronius/Loxone combination. Unfortunately I don't have any other Modbus devices to test.

[schurli]

with my Hoymiles DTU the timeout is set to already 2000ms. The way it is explained by Loxone it is the max time MS waits until a reply is returned from Modbus device. My interpretation would be that if after the preset timeout time has passed nothing has returned the MS just continuous to request the next value.
When I look in the Modbus monitor the time between a request and the corresponding reply is between 100 - 500 ms. So 2000ms seem reasonable to me.
I guess the higher this value is set the less chance that your Modbus device is "confused" by receiving two read requests without a reply?

[Tico]

That was also my understanding of how the Timeout should function. I find it unusual that my installation waits for the Timeout regardless of receiving a reply. I have the checkbox 'Fragmented Packets' checked. What is your setting?

Have you tried the 64bit sensor x 5 to see whether this stops the crashes? I anticipate the 64bit sensors won't straddle the entirety of the IO addressess you need. It is just to confirm what works with the Hoymiles DTU.

[schurli]

Hi Tico,
I cannot confirm that Loxone waits the timeout period before issuing the next read request. I have now increased the timeout value to 4000ms. A reply is typically received after 100 - 500ms from the device, and Loxone issues the next read request consistently 100-130 ms after it has received the reply from the previous request.
No, I have noit ticked the fragmented check box. Don't really understand what it does.
No, I haven't tried the 64 bit sensors. I my case all the registers are spread 20 bytes apart. So it wouldn't help there, I guess.

[Tico]

Ok, the Fragmented check box may have the effect of delaying the polling requests commensurate with the Timeout value. This is worth investigating in your installation.