spstigergenialkennt sich aussehr hilfreichhilfreich
- Bearbeitet
Und dann natürlich danach die PINs nochmal drehen, falls es noch nicht funktioniert.
Und dann natürlich danach die PINs nochmal drehen, falls es noch nicht funktioniert.
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.
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.
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.
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.
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.
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.
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.
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:
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.
Ü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.
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:
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?
schicke bitte auch einmal einen Screenshot der funktionierenden LOGO-Konfiguration für Modbus TCP
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.
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.