Einbindung von Modbus TCP

[ivande]

Laut Anleitung sind die Daten in zwei aufeinanderfolgenden 16 bit Registern

hast du einen Link zur Anleitung und evtl. einen Sceenshot der falsch gelesenen Register-Werte vom Plugin(Admin-Interface) - mit Angabe wie der Wert tatsächlich aussehen sollte.

Gruß Ivan

[fuppy]

Danke Tom Bombadil für deine schnelle Antwort.

Datentypen sollten passen. Laut Anleitung sind die Daten in zwei aufeinanderfolgenden 16 bit Registern gespeichert. Als Datentyp hab ich float32 ausgewählt. Bzgl. Endianess hab ich keine Infos. Aber da die Daten aber ja zeitweise passen, kann ich mir schwer vorstellen, dass es daran liegen kann... echt komisch...

[Tom Bombadil]

Erste fixe Ideen: Stimmen Datentyp / Endianess? Evtl sind nur High- und Lowbyte vertauscht (little vs big endian). Hatte das neulich in einer anderen Supportanfrage schon mal ...

/tom

[fuppy]

Hallo zusammen,
ich hoffe, dass mir hier jemand weiterhelfen kann.
Ich benutze ebenfalls das modbus_tcp Plugin in der Version 1.0.7. Ich möchte damit über einen Waveshare RS485 to ETH Converter ein EASTRON SDM-72D-M Zähler auslesen.
Insgesamt lese ich drei Werte aus. Auf den ersten Blick passt soweit auch alles.
Jedoch habe ich das Phänomen, dass in SHNG plötzlich unsinnige Werte angezeigt werden. Bei näherer Betrachtung stellt man fest, dass die Werte vertauscht sind.

Im Debug-Modus kann ich leider nicht sehen, ob der Fehler nun innerhalb des Plugins oder schon vorher stattfindet.

Ich hab parallel dann mit einem Modbus Client den Zähler respektive den Converter ausgelesen. Hier passen die Werte... deshalb mutmaße ich, dass im Plugin irgendetwas schief läuft.

Hat jemand ne Idee, wie ich dem Ganzen auf die Schliche kommen könnte?

Danke!

[Jackhammer]

Letzteres ist evtl. der richtige Hinweis.

Versuch mal bitte ein Register weiter unten (342) oder weiter oben (344). Vermutlich fängt Deine Registerübersicht bei 1 an, während die Adressierung bei 0 beginnt (nur die alternative 40.000er-Schreibweise fängt bei 40.001 an).
/tom

Minus 1 sieht gut aus. Werde das die Tage mit den anderen Registern verproben.

Das Gerät ist übrigens ein EASTRON SDM-72D-M V2, falls hier irgendwann noch jemand das Problem haben sollte :P

[Tom Bombadil]

Tom Bombadil: Danke für den Link. Ich komme aber dennoch nicht weiter.

Den angezeigten Wert aus SHNG bekomme ich in QModMaster angezeigt, wenn ich in den Setting als Base Address 0 auswähle.

Letzteres ist evtl. der richtige Hinweis.

Versuch mal bitte ein Register weiter unten (342) oder weiter oben (344). Vermutlich fängt Deine Registerübersicht bei 1 an, während die Adressierung bei 0 beginnt (nur die alternative 40.000er-Schreibweise fängt bei 40.001 an).

Ein Beispiel dafür hier - beide Arten der Adressierung für dasselbe Register sind in diesem Beispiel enthalten, die 'kleine' über die ID und die 'große' über HoldingRegister HR.

/tom

[Jackhammer]

Tom Bombadil: Danke für den Link. Ich komme aber dennoch nicht weiter.

Wenn ich das InputRegister 343 mit QModMaster auslese wird der Wert richtig angezeigt. In SHNG ist der Wert immer falsch, egal ob ich Endian.Big oder Little auswähle.
Den angezeigten Wert aus SHNG bekomme ich in QModMaster angezeigt, wenn ich in den Setting als Base Address 0 auswähle.
Das Item ist wie folgt konfiguriert:

    TotalActiveEnergy:
        type: num
        name: TotalActiveEnergy
        modBusObjectType: InputRegister     #(optional) default: HoldingRegister
        modBusAddress: 343
        modBusDataType: float32               #(optional) default: uint16
        modBusByteOrder: 'Endian.Big'    #(optional) default: 'Endian.Big'
        modBusWordOrder: 'Endian.Big'    #(optional) default: 'Endian.Big'
        #modBusDirection: 'read'       #(optional) default: 'read'
        #modBusUnit: 2                   #(optional) default: slaveUnit aus der Plugin-Konfig
        #modBusFactor: 0.1                  #(optional) default: 1
        #modBusDirection: read_write        #(optional) default: 'read'​

[tullsta]

Hallo,

nur ein kurzer Kommentar und falls doppelt bitte ignorieren:
bekam gestern eine Fehlermeldung beim Laden von modbus_tcp v1.0.7 mit pymodbus v3.0.2 / pymodbus3 v1.0.0:

ModuleNotFoundError: No module named 'pymodbus.client.sync'
No module named 'pymodbus.client.sync'

Hab' dann die Loesung die ich in pluggit von msinn gefunden haben uebernommen:

try:
    # for newer versions of pymodbus
    from pymodbus.client.tcp import ModbusTcpClient
except:
    # for older versions of pymodbus
    from pymodbus.client.sync import ModbusTcpClient

HTH + LG - tullsta

[Tom Bombadil]

Bei grundsätzlichen Fragen zu Modbus hilft evtl. --> das hier.

/tom

[Jackhammer]

Ja ich auch. Ich hatte verstanden, dass das wenigstens im Develop drin ist. Wie sollen die Leute denn das dann testen?



Geht das überhaupt? So wie ich das sehe muss man immer das komplette Release als Basis nehmen, was ich ehrlich gesagt als etwas umständlich erachte. Denn man hat Mühe überhaupt festzustellen, wo was geändert wurde. Einzeln runterladen kann man das ja bei github auch nicht - geht immer nur das komplette Paket. Oder ich stelle mich da auch zu doof für an.

ich hab mir mal den Stand aus deinem Repo geklont und in SHNG 1.9.3 in Betrieb genommen. Das Plugin läuft jetzt, ich bekomme auch Werte vom Bus. Die sind allerdings noch nicht richtig. Da das mein erster Modbus versuch ist kann das aber an mir liegen

[Msinn]

Da wird er nix finden, da Deine Änderungen noch nicht akzeptiert wurden. Die sind noch in einem 'Zwischenstadium', siehe oben. Irgendwann lernen wir beide vielleicht mal, wie man auf Github auch gegen *einzelne* Plugins *einzelne* PR's machen kann (ich bin zu doof dafür) - dann geht's wohl auch schneller.

Tom Bombadil Zu dem Kudelmuddel um diesen PR und den Aussagen dazu in diesem Thread habe ich Dir eine PN geschrieben.

[Cannon]

ich bin zu doof dafür

Ja ich auch. Ich hatte verstanden, dass das wenigstens im Develop drin ist. Wie sollen die Leute denn das dann testen?

einzelne* Plugins *einzelne* PR's machen kann

Geht das überhaupt? So wie ich das sehe muss man immer das komplette Release als Basis nehmen, was ich ehrlich gesagt als etwas umständlich erachte. Denn man hat Mühe überhaupt festzustellen, wo was geändert wurde. Einzeln runterladen kann man das ja bei github auch nicht - geht immer nur das komplette Paket. Oder ich stelle mich da auch zu doof für an.

[Tom Bombadil]

Schau mal im develop branch bei den plugins.

Da wird er nix finden, da Deine Änderungen noch nicht akzeptiert wurden. Die sind noch in einem 'Zwischenstadium', siehe oben. Irgendwann lernen wir beide vielleicht mal, wie man auf Github auch gegen *einzelne* Plugins *einzelne* PR's machen kann (ich bin zu doof dafür) - dann geht's wohl auch schneller.

/tom

[Cannon]

Reicht es vorübergehend auf eine 2.x Version von pymodbus zurück zu gehen oder klemmt es dann woanders?

pymodbus 3 setzt Python >= 3.8 voraus. Deshalb das ganze hin- und her. Nicht jeder hat Python 3.8 deshalb der Patch. Schau mal im develop branch bei den plugins. Ich weiß nicht genau welches das Problem macht. Ich meine aber, dass ich alle die pymodbus nutzen gefixt habe. Gern auch Feedback, ob die dann funktionieren.

[Tom Bombadil]

Offtopic:

Die Pull Requests mit den entsprechenden Anpassungen für etliche shNG Modbus-Plugins sind gestellt, aber von den Maintainern noch nicht in den Develop-Zweig gemerged (oh Herr, was für ein 'Deutsch'). Da hilft nur warten, oder selbst patchen.

Es geht bei dem PR der offen ist übrigens nicht um einen PR von Dir.

Das ist mir klar, und ich denke, das wissen wir beide.

Es ging um den Fakt, dass (Stand heute) von sechs offenen PR's drei die angesprochenen pymodbus-Anpassungen vornehmen; und zwar für insgesamt sieben (!) verschiedene Plugins. Zwei dieser drei PR's oxydieren da unkommentiert seit Mitte/Ende November rum, und bis jetzt wusste keiner der Autoren, wieso. Andere PR's wurden zwischenzeitlich innerhalb eines Tages quasi durchgewunken (z.B das Tank-Plugin, das offensichtlich auch ungetestet war und wo es sofort nach dem Mergen 'geknallt' hat).

Und ja, einer dieser beiden November-PR's ist von mir (Trovis+Helios RTU), der andere von Cannon (kostalmodbus + ksemmodbus + modbus_tcp + sma_mb - also der mit der Lösung für das hier von Jackhammer angesprochene Problem, der dieses vermutlich nicht hätte, wenn bereits gemerged wäre).

Allerdings tauchen sie dann auch nicht in der Dokumentation auf und würden aus Sicht des Projekts nicht als supportete Plugins gelistet.

Ist Wurst, da der Support ohnehin nicht mehr nur allein auf shNG beschränkt ist. Mittlerweile werden z.B. auf der Projektseite für die Trovis zwölf verschiedene Systemanbindungen von 'Direct KNX' bis hin zu SPS-Systemen gelistet. shNG dient in der Doku als Beispiel, weil es nun mal die erste Anbindung war - läuft aber bei den wenigsten der dort aktiven Mitleser.

Aber selbst in diesem Fall überwiegt für mich der Vorteil, im Fehler- oder Problemfall (wie z.B. der aktuellen pymodbus-Umstellung) über ein eigenes Repo schnell eine Lösung anbieten zu können, statt monatelang auf ein Merge warten zu müssen. Der aktuelle PR vom November bereitet diesen Schritt übrigens bereits vor; während das shNG-Plugin-Repo zukünftig nur noch alle notwendigen Dinge enthält, liefert das lokale Repo deutlich mehr Hintergrundinformationen und Tools.

Nimm das hier geschriebene bitte nicht als 'Universalkritik' - vor Deiner Arbeit, Deiner Geduld und Deinem Pragmatismus habe ich allerhöchsten Respekt. Aber im Fall dieser konkreten Anpassungen ist es einfach 'dumm gelaufen', und in Zukunft möchte ich nicht mehr meine Zeit in den Mehraufwand investieren, um 2 Repos synchron zu halten.

/tom

[Offtopic aus]

Edit: Falsch genannten Namen der Support-Anfrage korrigiert - Jackhammer statt Sipple.