Kostenfreier technischer Support

  Kostenfreier Versand innerhalb Deutschlands

  Kostenfreie Programmiersoftware

  für B2B-Kunden

spstiger Support-Community
  • Kinco HMIModbus
  • Kinco HMI > Daten Modbus RTU oder TCP auslesen funktioniert nicht.

HMI
Die Daten hab ich aus der Anleitung vom Zähler. Die bekommt man nur, wenn man den QR-Code auf der Verpackung vom Zähler scannt.
Hier mal ein Auszug:

  • spstigergenialkennt sich aussehr hilfreichhilfreich

PS: Das Kinco Protokoll (Port 2008) kannst du in deiner Geräteliste in den Netzwerkeinstellungen auch löschen. Das kann auch Fehlermeldungen verursachen. Dieses Protokoll brauchst du nur, wenn du mehrere Kinco HMI in einem Netzwerk hast, die untereinander auf ihre Variablen zugreifen sollen.

  • dibyx hat auf diesen Beitrag geantwortet.

    spstiger
    Hier die Einstellung von COM0:

    zu 1.
    Ich habe den TCP Master rausgenommen. --> Keine Änderung!

    Am DB9-Stecker habe ich die Pins 1 und 6 benutzt und ich habe die Adern auch schon mal gedreht. Es ändert sich aber nichts.

    Über Modbus TCP kommt ja eine Anfrage beim Wandler an, aber irgendwie scheint der Wandler mit der Anfrage nichts anfangen zu können. Ich habe auch das Protokoll Modbus RTU over TCP Slave benutzt. --> Keine Änderung!

    • spstigergenialkennt sich aussehr hilfreichhilfreich

    Deine Einstellungen sind wahrscheinlich falsch. Die Zähler haben im Standard keine Paritätsprüfung. Wenn du die nicht bewusst aktiviert hast, setze mal die Paritätsprüfung auf "keine". Dann sollte es funktionieren.

    • spstigergenialkennt sich aussehr hilfreichhilfreich

    • dibyx hat auf diesen Beitrag geantwortet.
      • spstigergenialkennt sich aussehr hilfreichhilfreich

      • Bearbeitet

      Und dann natürlich danach die PINs nochmal drehen, falls es noch nicht funktioniert.

      • spstigergenialkennt sich aussehr hilfreichhilfreich

      Wenn ihr die Paritätsprüfung aktiviert, wird pro Byte im seriellen Port ein zusätzliches Paritätsbit geschickt, um sicherzustellen, dass das Byte auch richtig ankommt:
      https://de.wikipedia.org/wiki/Parit%C3%A4tsbit

      Wenn das auf einer Seite aktiviert ist und der anderen nicht, dann kommt keine Kommunikation zu Stande.

      Eigentlich braucht ihr in Modbus nicht unbedingt eine Paritätsprüfung, da Modbus mit einer CRC-Prüfsumme eine eigene Fehlerprüfung auf der höheren Protokollebene hat.

      • spstigergenialkennt sich aussehr hilfreichhilfreich

      Und zum Konverter, keine Ahnung, was diese Darstellung mit den 8 Byte bedeuten soll. Eine einzelne Abfrage mit Function Code 4 (= Bereich 3X!) hätte genau 8 Byte, das wäre also richtig:

      https://www.simplymodbus.ca/FC04.htm

      138792 Byte sind sehr sehr viele Daten, das wären 17349 einzelne Modbus-Abfragen.

      • dibyx hat auf diesen Beitrag geantwortet.
        • Bearbeitet

        spstiger PS: Das Kinco Protokoll (Port 2008) kannst du in deiner Geräteliste in den Netzwerkeinstellungen auch löschen.

        Habe ich gemacht. --> Keine Änderung

        • spstiger hat auf diesen Beitrag geantwortet.
          • spstigergenialkennt sich aussehr hilfreichhilfreich

          Noch etwas, dein HMI hat in deiner Darstellung immer die IP 192.168.100.191, nicht 192.168.100.87. Gibt es mehrere HMI oder hast du die IP zwischenzeitlich geändert?

          Probier auch mal die Stationsnummer in DTools in Modbus TCP nicht auf 101, sondern auf 1 zu setzen. Eventuell verarbeitet das USR Gateway die Stationsnummer in Modbus TCP anders als du denkst.

          • dibyx hat auf diesen Beitrag geantwortet.
            • spstigergenialkennt sich aussehr hilfreichhilfreich

            dibyx

            Ja das hat auch nichts mit deinem eigentlichen Problem zu tun, ist nur ein Hinweis, dass du es nicht brauchst und es eventuell zusätzliche Fehlermeldungen verursachen kann.

            Dein echtes Problem für Modbus RTU ist wahrscheinlich einfach die Paritätseinstellung in der seriellen Konfiguration.

            • spstigergenialkennt sich aussehr hilfreichhilfreich

            Ich sehe gerade noch ein Problem in deiner Adressierung, auf das mich HMI gerade hingewiesen hat, da habe ich gar nicht richtig hingeschaut:

            Du hast Input Register in der Doku 3x. Das sind nur lesbare Register.

            Das heißt, du musst in der Adressierung im HMI den Bereich 3x auswählen und zum Beispiel die 271 für 30271.
            Die 3 in 30271 steht für 3X. Das ist die Adresskonvention für sogenannte Input-Register in Modbus.

            spstiger
            Ich habe im Zähler die Parität auf "even" gestellt. mit dieser Einstellung greift ja der Konverter auch auf die Zähler zu und fragt die Werte ab.

            spstiger 138792 Byte sind sehr sehr viele Daten, das wären 17349 einzelne Modbus-Abfragen.

            Der Konverter addiert in dieser Übersicht alle Anfragen und Antworten der Teilnehmer. Daran kann man erkennen, daß eine funktionierende Kommunikation stattfindet.

            • spstigergenialkennt sich aussehr hilfreichhilfreich

            Eventuell auch 272, aber ich glaube, dein Zähler fängt die Adressen auch bei 1 an zu zählen, dann brauchst du kein +1 und 271 funktioniert direkt.

            • spstigergenialkennt sich aussehr hilfreichhilfreich

            spstiger Noch etwas, dein HMI hat in deiner Darstellung immer die IP 192.168.100.191, nicht 192.168.100.87. Gibt es mehrere HMI oder hast du die IP zwischenzeitlich geändert?

            Mein HMI hat die 192.168.100.191 als feste IP. Die 192.168.100.87 ist die IP meines PC, da ich auf dem PC die "Direkte Online Simulation" durchführe.

            • spstigergenialkennt sich aussehr hilfreichhilfreich

            • Bearbeitet

            Wenn es mit der Adressierung gleich klappt, wirst du wahrscheinlich bei 32 Bit Werten ein weiteres Problem haben. Die Werte werden nicht richtig angezeigt. Das ist normal. Im Modbus ist nämlich die Wort-Reihenfolge für 32 Bit nicht standardisiert und jeder macht hier sein eigenes Ding (Modbus wurde nur für 16 Bit-Register entwickelt, daher gibt es keinen Standard für 32 Bit Werte).

            Zum Glück ist es in DTools 4.4 noch einfacher geworden, die Reihenfolge der Bytes und Words für Modbus RTU zu verändern, hier haben wir ein Video dazu:

            • dibyx hat auf diesen Beitrag geantwortet.
              • spstigergenialkennt sich aussehr hilfreichhilfreich

              Konkret kannst du hier die Byte- und Wort-Reihenfolge für 32 Bit (DWord) in 3x beliebig tauschen:

              Stell es einfach so ein, dass es passt vom Wert, falls die Standardeinstellung nicht gleich richtig ist.

              • spstigergenialkennt sich aussehr hilfreichhilfreich

              • Bearbeitet

              Übrigens, warum nutzt Kinco 3x bzw. 4x und nicht direkt 31037? Das ist ziemlich schlau:

              Der Modbus-Standard erlaubt für die Adressierung eigentlich bis zu 9999 Adressen, also für die Input-Register wären das in der Konvention 30000 - 39999.

              ABER: Für die Adressierung steht im Protokoll eigentlich ein Register mit 16 Bit zur Verfügung. Damit wären eigentlich Adressen bis 65535 technisch möglich. Nun gibt es tatsächlich Anbieter, die das nutzen, um sehr viele Adressen und Werte in einem einzelnen Modbus-Gerät bereitzustellen.

              Das Problem ist nur 30000 + 65535 = 95535, damit würden die Adressen andere Bereich überschreiben, zum Beispiel den 4x-Bereich für schreibbare Register (Holding Register), die laut Konvention in 40000 - 49999 sind.

              Deshalb nutzen einige Hersteller statt 30000 einfach 300000 als Startadresse für die Input-Register, bzw. 400000 statt 40000. Damit können Sie einfach 365535 adressieren.

              Und damit das auch mit den Kinco HMI funktioniert, nutzt Kinco einfach 3x oder 4x. Damit können 30000 und 300000 gleichermaßen adressiert werden. Im eigentlichen Protokoll wird nämlich die 3 oder 4 auch nicht mitgeschickt, das ist nur Adresskonvention. Damit funktioniert es für beide. Man muss halt nur die 3 oder 4 vorn in der Adresse weglassen.

              spstiger Wenn es mit der Adressierung gleich klappt,

              Klappt aber auch nicht. Ich bekomme nichts angezeigt und die Kommunikation zwischen HMI und Konverter findet nicht richtig statt.