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.

  • 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.

          • spstigergenialkennt sich aussehr hilfreichhilfreich

          • Bearbeitet

          Wir haben relativ viele Kunden, die diesen USR Adapter nutzen, der ist sehr beliebt. Grundsätzlich funktioniert es damit sehr gut. Natürlich auch mit direkter Modbus-RTU-Anbindung der Kincos, das haben wir hunderte Male konfiguriert.

          Gehen wir noch mal Schritt für Schritt durch, du hast viele Komponenten, da sollten wir eins nach dem anderen machen:

          1. Nimm dein neues Projekt mit dem Modbus TCP Slave Protokoll und nur einem USR-Adapter (wo keine anderen SPS konfiguriert sind)
          2. Nutze erst einmal den normalen Modbus TCP Adapter
          3. Setze eine Zahlenkomponente auf 3x 217 und eine zweite auf 3x 218 (das sind laut Doku Forward total active energy) jeweils als DWord
          4. Nimm die Logo vom Netz, damit die nicht in die Kommunikation reinfunkt (wenn es später funktioniert, kannst du probieren, ob beide gleichzeitig kommunizieren können)
          5. Probiere die Direkte Online-Simulation und prüfe, ob Daten ankommen

          Das HMI schickt anscheinend eine 8 byte Anfrage zum Konverter. Der Konverter antwortet aber nicht auf diese Anfrage. Das HMI bringt nach einer Weile die Meldung, dass der Server nicht bereit ist.
          Kann es eventuell etwas damit zu tun haben, dass der Konverter im Betriebsmodus TCP-Server steht?

          Das heißt ja dann, dass die LOGO als Client die Abfragen sendet. Das HMI steht aber auch auf TCP-Server. Kann denn überhaupt ein Server mit einem anderen Server kommunizieren?

          • spstigergenialkennt sich aussehr hilfreichhilfreich

          schicke bitte auch einmal einen Screenshot der funktionierenden LOGO-Konfiguration für Modbus TCP

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

            • Bearbeitet

            Das passt schon, dein USR ist ein Server (= alte Bezeichnung Slave) und dein HMI ist ein Client (= alte Bezeichnung Master). Das ist im Screenshot richtig eingestellt.

            • spstigergenialkennt sich aussehr hilfreichhilfreich

            Server not ready heißt übrigens meist, dass es ein Problem auf der Netzwerk-Kommunikationsebene gibt.
            Muss man im USR-Adapter eventuell einstellen, welcher Client zugreifen darf? Gibt es da eine Liste berechtigter Geräte?

            Probier doch mal die LOGO aus dem Netzwerk zu nehmen und dem HMI die IP der Logo zu geben.

            spstiger schicke bitte auch einmal einen Screenshot der funktionierenden LOGO-Konfiguration für Modbus TCP

            Dort kann man aber nicht viel sehen, da die Einstellungen für Modbus voreingestellt sind.